[RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code

[Sergey Bugaev]

On Sun, Feb 12, 2023 at 7:36 PM Samuel Thibault <samuel.thibault@gnu.org> wrote:
>
> Sergey Bugaev, le dim. 12 févr. 2023 19:25:11 +0300, a ecrit:
> > On Sun, Feb 12, 2023 at 7:11 PM Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > > Sergey Bugaev, le dim. 12 févr. 2023 14:10:42 +0300, a ecrit:
> > > > We should not need a getter routine, because one can simply inspect the target
> > > > thread's state (unless, again, I misunderstand things horribly).
> > >
> > > For 16bit fs/gs values we could read them from userland yes. But for
> > > fs/gs base, the FSGSBASE instruction is not available on all 64bit
> > > processors. And ATM in THREAD_TCB we want to be able to get the base of
> > > another thread.
> >
> > What I've meant is:
> >
> > __thread_get_state (whatever_thread, &state);
> > uintptr_t its_fs_base = state->fs_base;
> >
> > You can't really do the same to *write* [fg]s_base, because doing
> > thread_set_state on your own thread is bound to end badly.
>
> ? Well, sure, just like setting fs/gs through thread state was not done
> for i386.
>
> I don't see where you're aiming. Getting fs/gs from __thread_get_state
> won't actually give you the base, you'll just read something like 0.

It is my understanding that the actual values of fs/gs (i.e. the index
of a descriptor) are not useful on x86_64. But fs_base and gs_base are
now things that you have to store in the thread state and save/restore
on every context switch. fs_base and gs_base are like registers in
their own right (well, MSRs are registers). Thus, it should be easy to
read them from the state structure exposed by the kernel.

But again, I really have very little understanding of this, so maybe
I'm talking nonsense.

Sergey