Sergey Bugaev, le dim. 12 févr. 2023 19:51:33 +0300, a ecrit: > On Sun, Feb 12, 2023 at 7:36 PM Samuel Thibault <samuel.thiba...@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.thiba...@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.
Ah, so you mean adding the fs/gs bases to the thread_state content. I'd rather make it a separate state content, like we have a separate i386_DEBUG_STATE content. (And thus no need for a new RPC). Samuel
