From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by sourceware.org (Postfix) with ESMTPS id 7EBDA3858D37 for ; Thu, 20 Apr 2023 20:26:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7EBDA3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-b98d4cacf6aso140772276.0 for ; Thu, 20 Apr 2023 13:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682022381; x=1684614381; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WQNpsGp+cJg+ZNVDAkUg+Z9p9iUYPlKMUi4EpKM74Bk=; b=iurW51nNcJBUZWusmDq9PNmSHPUJ3XqlNtQRP/QwwJRYCjOyB+dCWyxlwKxIpgrcok tOP0CNPlKfFQj/03o+96zEmLSfHOvL5EplxHEoR0ZGvT1qHawNWZNedRNQH6HwVYxWnh wziNESeP5/eeTZcVbLebUWwwar534J3aDFwAfhUb6BAwJ/iGGeWdPCaa7iRZPoTFI9GZ gjxKanIDQwaaxqF/HR7jesy3UZk75vqUgqXF+Oo+oirYG+0TTkSGq/cF3TyVF4JA8tHW 66vXRkbH0KeZNdAt5sZKyZ3jI3NsO4ghGPskk3MQBa02oKdngVNY2W2iO/rLkEBlPM8M CVEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682022381; x=1684614381; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WQNpsGp+cJg+ZNVDAkUg+Z9p9iUYPlKMUi4EpKM74Bk=; b=AEnQq9BzF+Sm2epBNu1phDyFTTE9uybA0YR5Gl017oBVWV+S1d1O3yElVkWS3BhRyO HX9MtlpoeTQ3qsiY1etyHucDo5XCN0eqojAR+L2i613TXZMxtjA53sLElRCNTVwAqZ7t gpyjOZo5w11qcknOQdShWKgvzyCZGbpoYcYzgTrJH1CZnPXstWSk3eSGXQ4Ld7HM498x IIU1HYlfVEG0lNzPj5n0bq5UhDU6MwXIpXpktAVL4NEd6HjWE2qxm0VVIhwABMDnfu+C AevmwiQkvxDkldXsq0LesCB5dPNk45dbRnJ97v5IBrwSOCzannvltW12qD+oxP9rzBWV QPsA== X-Gm-Message-State: AAQBX9ejNfJDeb2WDR5WrLs/tnvYodzJV/NvfJVabCvgBPWg77QxuLtG iY6XQTqO9jZN3PKFOizmvwr/CHPyu5jPh1EKmDU= X-Google-Smtp-Source: AKy350bw0KZa1IBecTNBHsoAXR+wSU5CQ8dyiyD9NCuLMkTYOulo5KYKtrAhLJoZXcYGDGXjv5jfGnTB6+mV0cDZgOk= X-Received: by 2002:a25:ccd6:0:b0:b8b:fe5f:2eaa with SMTP id l205-20020a25ccd6000000b00b8bfe5f2eaamr145072ybf.2.1682022380683; Thu, 20 Apr 2023 13:26:20 -0700 (PDT) MIME-Version: 1.0 References: <20230420184220.300862-1-bugaevc@gmail.com> <20230420184220.300862-2-bugaevc@gmail.com> In-Reply-To: <20230420184220.300862-2-bugaevc@gmail.com> From: "H.J. Lu" Date: Thu, 20 Apr 2023 13:25:44 -0700 Message-ID: Subject: Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early To: Sergey Bugaev Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org, Samuel Thibault , Luca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3022.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On Thu, Apr 20, 2023 at 11:43=E2=80=AFAM Sergey Bugaev = wrote: > > Normally, in static builds, the first code that runs is _start, in e.g. > sysdeps/x86_64/start.S, which quickly calls __libc_start_main, passing > it the argv etc. Among the first things __libc_start_main does is > initializing the tunables (based on env), then CPU features, and then > calls _dl_relocate_static_pie (). Specifically, this runs ifunc > resolvers to pick, based on the CPU features discovered earlier, the > most suitable implementation of "string" functions such as memcpy. > > Before that point, calling memcpy (or other ifunc-resolved functions) > will not work. > > In the Hurd port, things are more complex. In order to get argv/env for > our process, glibc normally needs to do an RPC to the exec server, > unless our args/env are already located on the stack (which is what > happens to bootstrap processes spawned by GNU Mach). Fetching our > argv/env from the exec server has to be done before the call to > __libc_start_main, since we need to know what our argv/env are to pass > them to __libc_start_main. > > On the other hand, the implementation of the RPC (and other initial > setup needed on the Hurd before __libc_start_main can be run) is not > very trivial. In particular, it may (and on x86_64, will) use memcpy. > But as described above, calling memcpy before __libc_start_main can not > work, since the GOT entry for it is not yet initialized at that point. > > Work around this by pre-filling the GOT entry with the baseline version > of memcpy, __memcpy_sse2_unaligned. This makes it possible for early > calls to memcpy to just work. Once _dl_relocate_static_pie () is called, > the baseline version will get replaced with the most suitable one, and > that's what subsequent calls of memcpy are going to call. > > Also, apply the same treatment to __stpncpy, which can also be used by > the RPCs (see mig_strncpy.c), and is an ifunc-resolved function on both > x86_64 and i386. > > Tested on x86_64-gnu (!). > > Signed-off-by: Sergey Bugaev > --- > > Please tell me: > > * if the approach is at all sane > * if there's a better way to do this without hardcoding > "__memcpy_sse2_unaligned" > * are the GOT entries for indirect functions supposed to be statically > initialized to anything (in the binary)? if yes, why? if not, why is > PROGBITS and not NOBITS? > * am I doing all this _GLOBAL_OFFSET_TABLE_, @GOT, @GOTOFF, @GOTPCREL > correctly? > * should there be a !PIC version as well? does the GOT exist under > !PIC (to access indirect functions), and if it does then how do I > access it? it would seem gcc just generates a direct $function even > for indirect functions in this case. > > sysdeps/mach/hurd/i386/static-start.S | 7 +++++++ > sysdeps/mach/hurd/x86_64/static-start.S | 8 ++++++++ > 2 files changed, 15 insertions(+) > > diff --git a/sysdeps/mach/hurd/i386/static-start.S b/sysdeps/mach/hurd/i3= 86/static-start.S > index c5d12645..1b1ae559 100644 > --- a/sysdeps/mach/hurd/i386/static-start.S > +++ b/sysdeps/mach/hurd/i386/static-start.S > @@ -19,6 +19,13 @@ > .text > .globl _start > _start: > +#ifdef PIC > + call __x86.get_pc_thunk.bx > + addl $_GLOBAL_OFFSET_TABLE_, %ebx > + leal __stpncpy_ia32@GOTOFF(%ebx), %eax > + movl %eax, __stpncpy@GOT(%ebx) > +#endif > + > call _hurd_stack_setup > xorl %edx, %edx > jmp _start1 > diff --git a/sysdeps/mach/hurd/x86_64/static-start.S b/sysdeps/mach/hurd/= x86_64/static-start.S > index 982d3d52..81b3c0ac 100644 > --- a/sysdeps/mach/hurd/x86_64/static-start.S > +++ b/sysdeps/mach/hurd/x86_64/static-start.S > @@ -19,6 +19,14 @@ > .text > .globl _start > _start: > + > +#ifdef PIC > + leaq __memcpy_sse2_unaligned(%rip), %rax > + movq %rax, memcpy@GOTPCREL(%rip) > + leaq __stpncpy_sse2_unaligned(%rip), %rax > + movq %rax, __stpncpy@GOTPCREL(%rip) > +#endif > + > call _hurd_stack_setup > xorq %rdx, %rdx > jmp _start1 > -- > 2.40.0 > Doesn't it disable IFUNC for memcpy and stpncpy? --=20 H.J.