From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 791B63858D38 for ; Mon, 20 Feb 2023 17:10:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 791B63858D38 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-pj1-x1032.google.com with SMTP id pt11so2629227pjb.1 for ; Mon, 20 Feb 2023 09:10:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yhySOZDpOXQqwqkd8sOW5MX85ZKlbUuPPX0BZOTw79Q=; b=QMQr4PNEGJ/Zw3i69fXDkOWQegAHuINrJudoGCg2sian4rD8S2385y87OLtiYXOig/ v2qDFNkmWBWnspztpb08GJlCj5UeLbxaR3uvc8OYJgZ1tTHtYoitsEeA2VRlqMNjsZFL v351iWHiXEBEofxWLGzTq2gEIoR2wHRfPCpfhG1GUh/e/5JefbBq86YK13pEco4sTpCm 05W/CnGpf/99RVQjRP5ztHqMvi06ditQqgp5JT8XehpF08bq9oxzDlsm+E59AO+0NzIY EqRF5Tcr8p6MwWiE+IKO45qp3zX8+fw1wlO0ev4ZLmqd2o2Ev8bjHgQDBsS87c+BoNR5 Lh9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=yhySOZDpOXQqwqkd8sOW5MX85ZKlbUuPPX0BZOTw79Q=; b=5Ejsw5F6OLvoyPXGhvfznMBQpp2C2ecuLHqaZMYpybm/rN89NCUIby1qdzfxD0gWg1 Mwsb2joPCQvR8icnRQ514leJTmXrF94qCisqrFz7YtaxIBW67MEwp95QZ6uLvbBoyOBC mzS6cttyUTJ+FvKiERI9S+IZkJO+96MeYxpakibAdvvIavLW0qboKRoX3letGZHusYz7 iZJQewdsIQ5nnmYDvHv6d2DE5hyiVQyQ9uLl4aA0UxNGGYT5x/wgI/ZmkZC42Jrn24y6 3EmlWwWfk0HRin4xh4LhW3NdHMCHXj+d49juHuVBSXhTg1rjLjnjq/u2abyF4f6KfEuv Gf1w== X-Gm-Message-State: AO0yUKVxBvn2rRxA7MViFDxhX8o0Iib4WOySbIEuAaSE0f4l40bZH4oz veZZXAgD8lXlrZOJlpLTZJNRdJNGQcJ4kFQ9r9BWmsVKXwY= X-Google-Smtp-Source: AK7set8nLkYSwdmyU6JEixo7+WfXSxx1m49umNp1twFI2iAD55FvNnkGYqVfBqVKDyRGIjhPPX/gyKuvUzFH4uoc4NE= X-Received: by 2002:a17:90b:4d07:b0:233:d42f:a464 with SMTP id mw7-20020a17090b4d0700b00233d42fa464mr3526330pjb.137.1676913040215; Mon, 20 Feb 2023 09:10:40 -0800 (PST) MIME-Version: 1.0 References: <20230218203717.373211-1-bugaevc@gmail.com> <20230218203717.373211-8-bugaevc@gmail.com> <20230220000111.umchmzgk4vzgpayq@begin> In-Reply-To: From: Sergey Bugaev Date: Mon, 20 Feb 2023 20:10:29 +0300 Message-ID: Subject: Re: [RFC PATCH 7/9] hurd: Generalize init-first.c to support x86_64 To: Samuel Thibault Cc: bug-hurd@gnu.org, libc-alpha@sourceware.org, =?UTF-8?B?RmzDoXZpbyBDcnV6?= Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: > I wish I had a better understanding of just what's going on in this > file. Maybe a lot of the hacks can be rewritten in a nicer way. For > instance, do we really need to hijack the return addresses and jump to > init1 in this weird way, only to enable it to access argc/arg0? Since > we know where they are on our stack (__builtin_frame_address (0) + 2 > or something like that), can't we just pass it a pointer? > > Let me actually try just that... Eh, no, let's start even earlier than that. Please correct me if I (inevitably) get things wrong. _dl_init_first is Hurd-specific. It is called from the assembly code in dl-machine.h, specifically there's a RTLD_START_SPECIAL_INIT macro that's defined to call _dl_init_first on the Hurd, and to nothing otherwise. This RTLD_START_SPECIAL_INIT is used ("invoked") in i386/dl-machine.h, s390/s390-{32,64}/dl-machine.h, ia64/dl-machine.h, and alpha/dl-machine.h (but notably not in x86_64/dl-machine.h). In all cases, it's emphasized that "The special initializer gets called with the stack just as the application's entry point will see it; it can switch stacks if it moves these contents over." But I conclude that: - s390-gnu, ia64-gnu, and alpha-gnu ports are nonexistent, nor are they realistically ever going to happen, so we can ignore them completely - 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? The only thing it really needs, it seems, is a pointer to argc/argv/envp & Hurd data block *somewhere*. It does not have to be on the stack (though where else would it be), or immediately preceding its call frame -- all that really matters is that there's a pointer. 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? 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? Then again, we should be able to just use __builtin_frame_address (0) + 2 and avoid most of the hacks? Please tell me if this makes any sense. Sergey