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 717D33858CDA for ; Mon, 20 Feb 2023 17:31:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 717D33858CDA 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 1pUA0N-0007np-VB; Mon, 20 Feb 2023 12:31:11 -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=9Qa9w6h2Gr9dC5Fhh4IBvd2e7jFcnr2Ao9NN4YmKkuA=; b=kABto+ymL2bsp4fdvIUi uZqKb8HVtB91NQ3feAZ17/ldmaAYKxoPJQM27CckAgXcp8sgz8GE8UGLKUgrXSzI5vMIF5kxfCIZz QRn4ai20+OJGLiOWVFTk1/DfkIMSrjvLCtcueRuNmXLkj0jvkiPcV08R6iuQtT+A0VELe7WiWjVO1 Wjf9RCWL/aKleSQ/4p6GiRRVxP0HmkTA10B7y2M8Tq5KNSKxWEbQWQAGAPW5oSMQNyO6XJtpslZHG EtLHfl7B09qqBzYurd+3PnVS67f3Lo8+ZvB6j4/daMVJ8k5/ylCeknhd+nofZ2f9ooRR9V4SeM19x FOQ0wYfytSD60g==; Received: from nat-inria-interne-52-gw-01-bso.bordeaux.inria.fr ([194.199.1.52] helo=begin) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUA0N-0000y7-Lu; Mon, 20 Feb 2023 12:31:11 -0500 Received: from samy by begin with local (Exim 4.96) (envelope-from ) id 1pUA0K-007PgS-07; Mon, 20 Feb 2023 18:31:08 +0100 Date: Mon, 20 Feb 2023 18:31:08 +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 7/9] hurd: Generalize init-first.c to support x86_64 Message-ID: <20230220173107.sbwjegzbhb4hrkt6@begin> Mail-Followup-To: Sergey Bugaev , bug-hurd@gnu.org, libc-alpha@sourceware.org, =?utf-8?Q?Fl=C3=A1vio?= Cruz References: <20230218203717.373211-1-bugaevc@gmail.com> <20230218203717.373211-8-bugaevc@gmail.com> <20230220000111.umchmzgk4vzgpayq@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=-6.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no 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 lun. 20 févr. 2023 20:10:29 +0300, a ecrit: > - the implementation does not seem to actually switch stacks (in fact, > I have removed the unused switch_stacks function in the last commit) > -- so the "gets called with the stack just as the application's entry > point will see it" property may not be important anymore? That's possible, yes. > So my thinking goes, why don't we just hook into _dl_start, which > already has this very pointer? And in fact, _dl_start calls > _dl_sysdep_start, for which there is already a Hurd version. Can't we > just call our logic from there, and not worry about the stack layout > and overwriting return addresses? Possibly, yes. > That would work for the SHARED case; we also need to do something for > the static case. In that case, we are invoked by static-start.S; do I > understand it right that the argc/argv/whatever is still located > on-stack even on x86_64 in this case, and not passed in registers > according to the calling convention? I don't know. But you can check on Linux, we'll probably want to use the same ABI. Samuel