From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=ss5d=6I=deneb.enyo.de=fw@sourceware.org>
Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21])
	by sourceware.org (Postfix) with ESMTPS id 5CB2D3858D32
	for <libc-alpha@sourceware.org>; Sun, 12 Feb 2023 19:29:46 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5CB2D3858D32
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de
Received: from [172.17.203.2] (port=33285 helo=deneb.enyo.de)
	by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
	id 1pRI2h-00GUiL-Ml; Sun, 12 Feb 2023 19:29:43 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.94.2)
	(envelope-from <fw@deneb.enyo.de>)
	id 1pRI2h-00065Y-BS; Sun, 12 Feb 2023 20:29:43 +0100
From: Florian Weimer <fw@deneb.enyo.de>
To: Sergey Bugaev <bugaevc@gmail.com>
Cc: bug-hurd@gnu.org,  libc-alpha@sourceware.org,  =?iso-8859-1?Q?Fl=E1vio?=
 Cruz
 <flaviocruz@gmail.com>
Subject: Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code
References: <20230212111044.610942-1-bugaevc@gmail.com>
	<20230212111044.610942-12-bugaevc@gmail.com>
	<20230212161153.q4km4h2ql3k5pasp@begin>
	<CAN9u=Hf-HqYVaw-Z=hXypzsU6hPRycEK-A7+ch2aRBr7306tbw@mail.gmail.com>
	<20230212163607.47dynpr5rpbohrhe@begin>
	<87v8k6n8f9.fsf@mid.deneb.enyo.de>
	<20230212164651.opuy72eg2yjnxhmf@begin>
Date: Sun, 12 Feb 2023 20:29:43 +0100
In-Reply-To: <20230212164651.opuy72eg2yjnxhmf@begin> (Samuel Thibault's
	message of "Sun, 12 Feb 2023 17:46:51 +0100")
Message-ID: <87lel2n0m0.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <libc-alpha.sourceware.org>

* Samuel Thibault:

> Florian Weimer, le dim. 12 f=E9vr. 2023 17:40:58 +0100, a ecrit:
>> * Samuel Thibault via Libc-alpha:
>>=20
>> > Sergey Bugaev, le dim. 12 f=E9vr. 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=E9vr. 2023 14:10:42 +0300, a ecrit:
>> >> > > We should not need a getter routine, because one can simply inspe=
ct 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 bas=
e of
>> >> > another thread.
>> >>=20
>> >> What I've meant is:
>> >>=20
>> >> __thread_get_state (whatever_thread, &state);
>> >> uintptr_t its_fs_base =3D state->fs_base;
>> >>=20
>> >> 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.
>>=20
>> 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.