bug-hurd
[Top][All Lists]
Advanced

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

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


From: Florian Weimer
Subject: Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code
Date: Sun, 12 Feb 2023 20:29:43 +0100

* Samuel Thibault:

> Florian Weimer, le dim. 12 févr. 2023 17:40:58 +0100, a ecrit:
>> * Samuel Thibault via Libc-alpha:
>> 
>> > 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.
>> 
>> The convention is that the FSBASE address is at %fs:0.
>
> Yes, but that works only for reading your own base, not the base of
> another thread.

Well, yes, but how do you identify the other thread?  Usually by the
address of its TCB.



reply via email to

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