From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) by sourceware.org (Postfix) with ESMTPS id 8ECC2384D1A5 for ; Thu, 20 Oct 2022 17:01:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8ECC2384D1A5 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-qt1-x82c.google.com with SMTP id h24so13759230qta.7 for ; Thu, 20 Oct 2022 10:01:53 -0700 (PDT) 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=+zeP5SN8wguZ0eZnk2cEVe3LSb7sc6xIzl0wONvs1L0=; b=X3pkjK8JbV/hJWBB3BLASm/iWE9dJfS3a+NSj1Yml88QOgJnGwSBofL+W0nT+O4tGN 9vWggi19sTmpuAnDe7ceas0Pp6UFSO479MP9A36LAeilnpQwz8/9MOKEDXN3lvKkGc23 xODxchsmW16xFvlSc2enAMLqr88OoEY+7Wo1ez2CX7SBOp/4vJr2JyD42MOAdwjom3ln kVTHJfRiSZaM2C7f8PEUQqk6MTdo8+YJUREi1+YSu79wFejWpAivVKjuKg0Eachn33Ub iIlgY4TKC2v30wK8K9D62JqsJgfyYgu6jLiPaaJ4OlA0WM+QaBMSu020cu7rDJBSpoM/ PFlg== 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=+zeP5SN8wguZ0eZnk2cEVe3LSb7sc6xIzl0wONvs1L0=; b=K5Gw94BgCaUvgtGR/Jg/0jH9Kw4EmktjsDae3QnwCsNEEJIeZJ0XfYC1r00Ft/0rBE tdl2UD6u0cJ6NrtQWpchdTam/JSqXDJzqfe9UYIqAEJA5F7/1wcAkJWd4U7GpkNt/sip AEPaH0cLwtz10A05QAHzV+cR9lYZx6b4nZcvDRLcxwJwGCkTzrfm9sIzJRpmdvar/Q3k lm3VR2xVNtT7+m1lOoSQpzB5lK3PdN4MaTXKm2EpBCj353yMNXVzg9UcwVXd6jIanGLJ 1HHaIiomdCR/KTzMgziBiZqCfpktrK5TVW9buT41ykkDlRoNH8ddpBFfOrCKQJQjhfvr m3ZQ== X-Gm-Message-State: ACrzQf1CS0b2SHQBIhF30UQ6Y4U0BLT1UmGdcEuXIhMY9+v5UrguX7ES wUf2nx3gM+2293tCvhVXnxlGty3i36YrqNZvrXM= X-Google-Smtp-Source: AMsMyM4pbgvhMq+1r7LspnK4o8EYQ/5TEyongDelettKC30deZEAHGFQY4h8KtqknNKFH5PsqUCrx2Gn+xx6lqLhAtU= X-Received: by 2002:ac8:4e53:0:b0:39c:eec4:373f with SMTP id e19-20020ac84e53000000b0039ceec4373fmr11591245qtw.617.1666285312188; Thu, 20 Oct 2022 10:01:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Thu, 20 Oct 2022 10:01:15 -0700 Message-ID: Subject: Re: x86-64: Use only one default max-page-size To: Michael Matz Cc: binutils@sourceware.org, Alan Modra Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3024.5 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 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, Oct 20, 2022 at 7:42 AM Michael Matz wrote: > > On x86-64 the default ELF_MAXPAGESIZE depends on a configure > option (--disable-separate-code). Since 9833b775 > ("PR28824, relro security issues") we use max-page-size for relro > alignment (with a short interval, from 31b4d3a ("PR28824, relro > security issues, x86 keep COMMONPAGESIZE relro") to its revert > a1faa5ea, where x86-64 used COMMONPAGESIZE as relro alignment > target). > > But that means that a linker configured with --disable-separate-code > behaves different from one configured with --enable-separate-code > (the default), _even if using "-z {no,}separate-code" option to use > the non-configured behaviour_ . In particular it means that when > configuring with --disable-separate-code the linker will produce > binaries aligned to 2MB pages on disk, and hence generate 2MB > executables for a hello world (and even 6MB when linked with > "-z separate-code"). > > Generally we can't have constants that ultimately land in static > variables be depending on configure options if those only influence > behaviour that is overridable by command line options. > > So, do away with that, make the default MAXPAGESIZE be 4k (as is default > for most x86-64 configs anyway, as most people won't configure with > --disable-separate-code). If people need more they can use the > "-z max-page-size" (with would have been required right now for a > default configure binutils). > > bfd/ > * elf64-x86-64.c (ELF_MAXPAGESIZE): Don't depend on > DEFAULT_LD_Z_SEPARATE_CODE. > --- > > I was worried about this case already earlier the year > (https://sourceware.org/pipermail/binutils/2022-February/119766.html), but > at that time I didn't realize that not only an explicit request via > -z max-page-size generates large binaries, but also just configuring > binutils different would do so. > > For compatibility with old code streams I do have to configure binutils in > such way and obviously we can't have that produce 2MB or 6MB binaries. > > --- > bfd/elf64-x86-64.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c > index f3b54400013..2ae8dffba0f 100644 > --- a/bfd/elf64-x86-64.c > +++ b/bfd/elf64-x86-64.c > @@ -5259,11 +5259,7 @@ elf_x86_64_special_sections[]= > #define ELF_ARCH bfd_arch_i386 > #define ELF_TARGET_ID X86_64_ELF_DATA > #define ELF_MACHINE_CODE EM_X86_64 > -#if DEFAULT_LD_Z_SEPARATE_CODE > -# define ELF_MAXPAGESIZE 0x1000 > -#else > -# define ELF_MAXPAGESIZE 0x200000 > -#endif > +#define ELF_MAXPAGESIZE 0x1000 > #define ELF_COMMONPAGESIZE 0x1000 > > #define elf_backend_can_gc_sections 1 > -- > 2.37.3 OK. Thanks. -- H.J.