From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id E98FD3858C54 for ; Sun, 12 Feb 2023 16:36:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E98FD3858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRFKj-0004oP-Ge; Sun, 12 Feb 2023 11:36:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=In-Reply-To:MIME-Version:References:Subject:To:From: Date; bh=panQvk/TRgpYINuG/BGwRvc8A9ARbKa25pjFjYhH5Gs=; b=ppBUjLIMivrc2Df44LRj eRYQyYIuOngSEwHd1KGh1fQyjWKHeumbxmwQWEKk1GomTCEIYNLj2sr+5jo3bIds+Z9jqtlKRDgxe bVAoP+R1TP6Doljec64cw1/lqpl/ktSRirVS1EFM7zSm442EkAPmsgjwO/DDL+YGt8VC8b1+8zZgz Ny+zPdEGXat+F6sPocPd4A8kl3C0dR1KKb8O+x1csa8yPLXAoD9wzmsnoyJdQDAFM4toNdIV5GlPa DQJkJaQpPolYfFgt3Yzpikmc/wr4tEtKrDmqj+UnaIxRifOaBRPcI6gMWKOFwvww7wyy+4bchbGo7 JobCJptm2FI6Sg==; Received: from lfbn-bor-1-1163-184.w92-158.abo.wanadoo.fr ([92.158.138.184] helo=begin) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRFKj-00058H-3j; Sun, 12 Feb 2023 11:36:09 -0500 Received: from samy by begin with local (Exim 4.96) (envelope-from ) id 1pRFKh-005QEd-2O; Sun, 12 Feb 2023 17:36:07 +0100 Date: Sun, 12 Feb 2023 17:36:07 +0100 From: Samuel Thibault To: Sergey Bugaev Cc: bug-hurd@gnu.org, libc-alpha@sourceware.org, =?utf-8?Q?Fl=C3=A1vio?= Cruz Subject: Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code Message-ID: <20230212163607.47dynpr5rpbohrhe@begin> Mail-Followup-To: Sergey Bugaev , bug-hurd@gnu.org, libc-alpha@sourceware.org, =?utf-8?Q?Fl=C3=A1vio?= Cruz References: <20230212111044.610942-1-bugaevc@gmail.com> <20230212111044.610942-12-bugaevc@gmail.com> <20230212161153.q4km4h2ql3k5pasp@begin> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_PASS,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: 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 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. > > > diff --git a/sysdeps/mach/hurd/x86_64/static-start.S b/sysdeps/mach/hurd/x86_64/static-start.S > > > new file mode 100644 > > > index 00000000..982d3d52 > > > --- /dev/null > > > +++ b/sysdeps/mach/hurd/x86_64/static-start.S > > > @@ -0,0 +1,27 @@ > > > +/* Type of the TCB. */ > > > +typedef struct > > > +{ > > > + void *tcb; /* Points to this structure. */ > > > + dtv_t *dtv; /* Vector of pointers to TLS data. */ > > > + thread_t self; /* This thread's control port. */ > > > + int __glibc_padding1; > > > + int multiple_threads; > > > + int gscope_flag; > > > + uintptr_t sysinfo; > > > + uintptr_t stack_guard; > > > + uintptr_t pointer_guard; > > > + long __glibc_padding2[2]; > > > + int private_futex; > > > > ? Isn't that rather feature_1 ? > > sysdeps/mach/hurd/i386/tls.h has 'int private_futex;', which is where > I stole this from. A quick grep confirms that it's never used, Yes, this was just to align on the nptl tls.h. But apparently that got renamed and hurd's tls wasn't updated. > so we might rename both to feature_1, or maybe another instance of > __glibc_padding. Better stay coherent with the nptl version. > > > +/* GCC generates %fs:0x28 to access the stack guard. */ > > > +_Static_assert (offsetof (tcbhead_t, stack_guard) == 0x28, > > > + "stack guard offset"); > > > +/* libgcc uses %fs:0x70 to access the split stack pointer. */ > > > +_Static_assert (offsetof (tcbhead_t, __private_ss) == 0x70, > > > + "split stack pointer offset"); > > > > Indeed. Could you perhaps also add them to the i386 tls.h? > > > > +/* Install new dtv for current thread. */ > > > +# define INSTALL_NEW_DTV(dtvp) THREAD_SETMEM (THREAD_SELF, dtv, dtvp) > > > +/* Return the address of the dtv for the current thread. */ > > > +# define THREAD_DTV() THREAD_GETMEM (THREAD_SELF, dtv) > > > > While at it, try to make the i386 version use that too? > > Yeah, I have not ported the improvements back to the 32-bit version; > maybe I should. Better always keep things as coherent as possible. Otherwise another you will later wonder why in the hell we have differences between the two versions. > Another cool one is doing fs/gs-relative access using > GCC's __seg_fs/__seg_gs when supported. Yes, that's nice indeed! Samuel