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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 15BBB1F44D for ; Mon, 25 Mar 2024 12:24:53 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=PrZKibpB; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 71CCC3858403 for ; Mon, 25 Mar 2024 12:24:51 +0000 (GMT) Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) by sourceware.org (Postfix) with ESMTPS id 9CDA83858D39 for ; Mon, 25 Mar 2024 12:24:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9CDA83858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9CDA83858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4860:4864:20::32 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711369469; cv=none; b=gaVbhLVgL8MNg1GfV+N+HNId9r9ySn5/sIca5ZRPSjNLiTvGqq4OocVty3eKGebLiP0Q6yAgAYBXUyzVEC/v6II0jpNoUIFgIPs1xGdiHvN7/EKJeNPG8wht0j6uJgfsEzDI7XfxsB1tp9w4vPFY4s037giHpuH7cycECHlck9g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711369469; c=relaxed/simple; bh=5/fdjjhG2I6Gyb9TrWYZKm5Y7ynlMqew9oc588k7OaE=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=tDEdrY8IgryxdeSSrENMBGD+ODG8Hr7gN5ID1Hdn0+Fl099CPhOfqkEOxGwvJJtAK3ZYgVEMnAWikNJrOCIaM2cieMde7hRVUqNB9NT8VhYgtM5dx0h3HKJkvTIqMiXa8Vaty6gPGJOPU65qKyNRViGPlAqJFDAKYtFBpqzArS0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-22195b3a8fbso3188573fac.3 for ; Mon, 25 Mar 2024 05:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711369466; x=1711974266; darn=sourceware.org; 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=5/fdjjhG2I6Gyb9TrWYZKm5Y7ynlMqew9oc588k7OaE=; b=PrZKibpBfIXspgnHvRsdAeGhXOT+UHh4rXKJn7dGNI8aO9Hs8ZpjfLDLaGfAecrYK/ lyObzzwBJtCWeW+z9xCTXh5RhkoqLNM4OkcdWekjJgGOjAU3L3Uv/eNsDB5t0UTcdwBW GByednnOPQXWeECYl6sdTZ5Mv3qsLCWy/SAODCkhbP7y1y8l82r9p2zgHdltb4C+vapv zQKzVzFxN6wWTbUxy1sj8woMQrtJrmq14AN+UUWGHzI01V4pjCMIL1eBphLQSQ3UYD0w VmCWTA1filda0qJjvVJFVHPnGwpz2ESm1gLX8ladNoyraISaNGj9V5bzqGWtsNH1pbeN my/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711369466; x=1711974266; 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=5/fdjjhG2I6Gyb9TrWYZKm5Y7ynlMqew9oc588k7OaE=; b=tOTxaQJE7rh1xwaeh9N0DwNGobTRf8gIJA6gsLgH0VxBOVqHax9sxi5ttBBUSJp9Go 9RR9FANrhR67DVcIGa5PUNa7rNUIOvOXv2cI5skxOSAv8vALEoUfBNX+XSg+XNNAanMP /3vUbzPTXqts+Hg6gtNlRKtL1yzIbZ+AkX/vIfhseV8mMwdtuWspbIEhY4Jb0no0Bgni M4nTeiqg+SYD7jbxCjT2tTjhHo6yZTfMPI1ejGsYSVnfLNfhSXNI0y0KbqYUNEKYkksi m4cGt8RTlkciQbbP9g0jSKUglG/2/yERXMDZy6eUuMtVRYN0JZmQkpIzaKravbwbBrLi Yz1Q== X-Gm-Message-State: AOJu0YzWQMZ9H7KH4Q/B4re4C2ZDe/NW5oCm+T0UOKFL9amY8ca0usoQ QDuuHv6COstp/kMorVPzAgTzMf8sdnOAcpzWCRjOLc3fxMRm9zxwnM4kKFQQqQD90oE9W043t0M 78T4CXgHJX1RJVuhe1UWMWXJDHJs= X-Google-Smtp-Source: AGHT+IFz0Dh70U0HA0aVmzfjcIqBNk+H/nkj8Id2xWelB3ZE+ZuSUqE+w2qjQNq+i5dt2LmgvI8TB3I16VRCjJoiptA= X-Received: by 2002:a05:6870:d8c7:b0:220:65ba:ca3a with SMTP id of7-20020a056870d8c700b0022065baca3amr8442762oac.14.1711369465760; Mon, 25 Mar 2024 05:24:25 -0700 (PDT) MIME-Version: 1.0 References: <20240103171502.1358371-1-bugaevc@gmail.com> <20240103171502.1358371-4-bugaevc@gmail.com> <87y1aon3vc.fsf@oldenburg.str.redhat.com> <877chqa5gq.fsf@oldenburg.str.redhat.com> In-Reply-To: <877chqa5gq.fsf@oldenburg.str.redhat.com> From: Sergey Bugaev Date: Mon, 25 Mar 2024 15:24:14 +0300 Message-ID: Subject: Re: [RFC PATCH 03/23] Allow glibc to be compiled without EXEC_PAGESIZE To: Florian Weimer , Samuel Thibault Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Hello, On Mon, Mar 25, 2024 at 2:58=E2=80=AFPM Florian Weimer = wrote: > > I think the intent here is to initialize _dl_pagesize with a > > conservative default, to avoid initialization ordering issues. > > EXEC_PAGESIZE is supposed to be largest supported page size. > > This was committed without addressing the comment above. yes, I also didn't expect this to get pushed until we come to an agreement = here. On topic: I understand that this must have been done this way because of potential initialization order issues (and the mail I linked also makes this guess). The question is, is that (working around initialization order issues) actually required, or is that a leftover from something that's no longer relevant (or perhaps never was)? Things seem to still work with this patch on aarch64-gnu for me, both in SHARED and !SHARED, though I obviously didn't test every potential codepath. I was hoping that some broader testing, such as running the testsuite on CI on existing ports, could answer that question comprehensively -- though now I realize that since this patch leaves the initialization as-is when EXEC_PAGESIZE is defined (i.e. everywhere but on aarch64-gnu), CI wouldn't catch any issues that removing it would cause. We could define EXEC_PAGESIZE to some conservative value on aarch64-gnu too, if it turns out that this little workaround is really required. But it seems cleaner to make sure we don't need to, as Roland's email suggests, and introducing a new port that doesn't have a fixed page size (and doesn't come with an EXEC_PAGESIZE value already defined in kernel headers) seems to be a good opportunity to do that. That's my reasoning here. Sergey