[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 17:40:58 +0100 |
* 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. The x86-64 TLS
ABI assumes this, so that it's possible to compute the global (not
thread-specific) address of a TLS variable.
- [RFC PATCH glibc 12/12] C11 thrd: Downgrade the default alignment of mtx_t, (continued)
- [RFC PATCH glibc 5/12] htl: Fix semaphore reference, Sergey Bugaev, 2023/02/12
- [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code, Sergey Bugaev, 2023/02/12
- Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code, Samuel Thibault, 2023/02/12
- Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code, Sergey Bugaev, 2023/02/12
- Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code, Samuel Thibault, 2023/02/12
- Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code,
Florian Weimer <=
- Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code, Samuel Thibault, 2023/02/12
- Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code, Florian Weimer, 2023/02/12
- Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code, Samuel Thibault, 2023/02/12
- Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code, Sergey Bugaev, 2023/02/12
- Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code, Samuel Thibault, 2023/02/12
- Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code, Sergey Bugaev, 2023/02/12
Re: [RFC PATCH 0/12] Towards glibc on x86_64-gnu, Samuel Thibault, 2023/02/12