From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 748D81F451 for ; Thu, 4 Jan 2024 22:47:42 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=SGTGy2R6; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7FE23386F805 for ; Thu, 4 Jan 2024 22:47:41 +0000 (GMT) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 1EE733858C52 for ; Thu, 4 Jan 2024 22:47:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1EE733858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1EE733858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704408439; cv=none; b=ijOCDOwkR3IN4ZrEnd/hcO7qqVviXcfsqkYPkWzp8aZs4hU3IjimlxKNQPRPCoRQ7/46x2jNhu0LG59hGKuK6Sx6z+vHEePJgLXqcasZGiJeETNPHpcMgiWENG72xW6+kCY+3omnI8uq4r2UAeTfxtmGSJ+KobgrS+CCjx4ZKjg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704408439; c=relaxed/simple; bh=69CHG9rpHuj0CmM6GTM8BgBSdvklVeYedNPx/whORwo=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=e9O4t3751vNQjQoMMa6okSj6rSgEG/lMiqX/W4AqsLmJMCK1rPrG5e4lUEHTrUVyd5M0HuyfOw/3DGgCx7PucJgbTmNUW1oK677DMjxtq9o9mKOEsk1cTp8crvv8MF1bt3JEzKKsxDvMHvaS3wsX4Y8FoZViZu1f5NS1/mGshR0= ARC-Authentication-Results: i=1; server2.sourceware.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 1rLWUd-0007RX-MY; Thu, 04 Jan 2024 17:47:15 -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=5BrUiuGIhDWwYRhmWqyBBRw588KWAPB2nc75WYkPFXs=; b=SGTGy2R61lx8uJoi7Li3 Dm0BcKcblism4NO9jvs6LGEtAXXuEsR1hGeJ6nMX+GsgrtpRqWfUVmJQGgDdJyTq3evHH1x5aiiFy wKTYZ94UZJJWn0SWoEmE/ZF28MXeoZPBsaljyVD1HLC/rqTj0uPDFaX/2p8jioLFol5/pYE/ke3Do bAgc0MQ6rj0gjdBv3nvWWex0QVYF4BEysUoQA11cL+akqp63lihM8x3kMciuIkAEZvtvrNHasY5mP vhqc6fLAF4cnPowWI1lKcoFwuQcNEp61M99EyQLX8wPrQdZZMaXvazcr4bbMP2AmNZP14NYkTW06J pI8p6y1jWUJFMg==; Date: Thu, 4 Jan 2024 23:47:12 +0100 From: Samuel Thibault To: Sergey Bugaev Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org Subject: Re: [RFC PATCH 07/23] hurd: Pass the data pointer to _hurd_stack_setup explicitly Message-ID: <20240104224712.ytpwgdbcpmknivhh@begin> Mail-Followup-To: Sergey Bugaev , libc-alpha@sourceware.org, bug-hurd@gnu.org References: <20240103171502.1358371-1-bugaevc@gmail.com> <20240103171502.1358371-8-bugaevc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240103171502.1358371-8-bugaevc@gmail.com> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Applied, thanks! Sergey Bugaev, le mer. 03 janv. 2024 20:14:40 +0300, a ecrit: > Instead of relying on the stack frame layout to figure out where the stack > pointer was prior to the _hurd_stack_setup () call, just pass the pointer > as an argument explicitly. This is less brittle and much more portable. > > Signed-off-by: Sergey Bugaev > --- > sysdeps/mach/hurd/i386/static-start.S | 3 +++ > sysdeps/mach/hurd/x86/init-first.c | 16 +++++++--------- > sysdeps/mach/hurd/x86_64/static-start.S | 1 + > 3 files changed, 11 insertions(+), 9 deletions(-) > > diff --git a/sysdeps/mach/hurd/i386/static-start.S b/sysdeps/mach/hurd/i386/static-start.S > index d83505b2..3ffcb47d 100644 > --- a/sysdeps/mach/hurd/i386/static-start.S > +++ b/sysdeps/mach/hurd/i386/static-start.S > @@ -19,7 +19,10 @@ > .text > .globl _start > _start: > + pushl %esp > call _hurd_stack_setup > + /* No need to "addl %4, %esp", since _hurd_stack_setup > + * returns with an already adjusted stack pointer. */ > xorl %edx, %edx > jmp _start1 > > diff --git a/sysdeps/mach/hurd/x86/init-first.c b/sysdeps/mach/hurd/x86/init-first.c > index bb051418..6f71d71b 100644 > --- a/sysdeps/mach/hurd/x86/init-first.c > +++ b/sysdeps/mach/hurd/x86/init-first.c > @@ -197,7 +197,7 @@ strong_alias (posixland_init, __libc_init_first); > which should not exist at all. */ > void > inhibit_stack_protector > -_hurd_stack_setup (void) > +_hurd_stack_setup (void **argptr) > { > /* This is the very first C code that runs in a statically linked > executable -- calling this function is the first thing that _start in > @@ -206,14 +206,12 @@ _hurd_stack_setup (void) > > _start1 expects the arguments, environment, and a Hurd data block to be > located at the top of the stack. The data may already be located there, > - or we may need to receive it from the exec server. */ > - void *caller = __builtin_extract_return_addr (__builtin_return_address (0)); > - /* If the arguments and environment are already located on the stack, this is > - where they are, just above our call frame. Note that this may not be a > - valid pointer in case we're supposed to receive the arguments from the exec > - server, so we can not dereference it yet. */ > - void **p = (void **) __builtin_frame_address (0) + 2; > + or we may need to receive it from the exec server. If the data is located > + on the stack (just above our call frame), argptr points to it. Note that > + this may not be a valid pointer in case we're supposed to receive the > + arguments from the exec server, so we can not dereference it yet. */ > > + void *caller = __builtin_extract_return_addr (__builtin_return_address (0)); > /* Init the essential things. */ > first_init (); > > @@ -245,7 +243,7 @@ _hurd_stack_setup (void) > the stack pointer to the data (which is somewhere on the current stack > anyway). This way, _start1 find the data on the top of the stack, just as > it expects to. */ > - _hurd_startup (p, &doinit); > + _hurd_startup (argptr, &doinit); > __builtin_unreachable (); > } > #endif > diff --git a/sysdeps/mach/hurd/x86_64/static-start.S b/sysdeps/mach/hurd/x86_64/static-start.S > index 9b9db937..0ec00905 100644 > --- a/sysdeps/mach/hurd/x86_64/static-start.S > +++ b/sysdeps/mach/hurd/x86_64/static-start.S > @@ -25,6 +25,7 @@ _start: > leaq __strlen_sse2(%rip), %rax > movq %rax, strlen@GOTPCREL(%rip) > > + movq %rsp, %rdi > call _hurd_stack_setup > xorq %rdx, %rdx > jmp _start1 > -- > 2.43.0 > > -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria.