public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Michael Matz <matz@suse.de>
To: binutils@sourceware.org
Cc: Alan Modra <amodra@gmail.com>, "H.J. Lu" <hjl.tools@gmail.com>
Subject: x86-64: Use only one default max-page-size
Date: Thu, 20 Oct 2022 14:42:25 +0000 (UTC)	[thread overview]
Message-ID: <alpine.LSU.2.20.2210201432170.29399@wotan.suse.de> (raw)

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

             reply	other threads:[~2022-10-20 14:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-20 14:42 Michael Matz [this message]
2022-10-20 17:01 ` H.J. Lu
2022-10-20 17:35   ` Fangrui Song
2022-10-25 15:44     ` Michael Matz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.20.2210201432170.29399@wotan.suse.de \
    --to=matz@suse.de \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).