[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 8/9 gnumach] Add i386_fsgs_base_state

From: Sergey Bugaev
Subject: Re: [RFC PATCH 8/9 gnumach] Add i386_fsgs_base_state
Date: Sun, 19 Feb 2023 00:55:54 +0300

On Sun, Feb 19, 2023 at 12:34 AM Luca <luca@orpolo.org> wrote:
> Hi!
> Il 18/02/23 21:37, Sergey Bugaev ha scritto:
> > +struct i386_fsgs_base_state {
> > +     unsigned long fs_base;
> > +     unsigned long gs_base;
> > +};
> The fs and gs registers are also set by i386_REGS_SEGS_STATE. If they
> are better set separately (as it seems from the other patch, but I don't
> really know the glibc hurd part) should we remove them from the
> i386_REGS_SEGS_STATE case for x86_64, to avoid conflicts?


This state controls fs/gs *base* addresses, not the actual values of
the fs/gs registers. Base addresses are used when you use fs- (or gs-)
relative addressing:

mov %fs, %rbx  // rbx = fs (the register itself)
mov %fs:0x1234, %rax  // rax = memory[fs_base + 0x1234] (the base address)

On i386, fs/gs _base addresses_ are set by setting up some segment
descriptors (no idea if that's the correct term) and placing the
segment selector into the fs/gs *register*. On x86_64, you're
apparently not supposed to use segmentation, and instead there is a
MSR that you write to (and read from?) to access fs and gs base
addresses. I don't know whether fs/gs values actually influence
anything, or are relevant/significant for anything on x86_64. I don't
know how segmentation and MSR values interact / don't conflict when a
x86_64 machine runs i386 code (maybe it's dependent on long mode or

Should the same i386_fsgs_base_state API be made available on i386? On
the one hand, this seems like a nice abstraction, but on the other
hand userland would not be able to use it anyway out of compatibility
concerns -- even now glibc has two different code paths for kernels
that do or do not support i386_{g,s}et_gdt ...

Please also see this discussion from last week:

And again, I don't really know anything about this, mabe what I'm
saying makes no sense. That's why I'm asking for feedback: whether
this API looks reasonable or not.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]