From: Michael Matz <matz@sourceware.org>
To: bfd-cvs@sourceware.org
Subject: [binutils-gdb] x86-64: Use only one default max-page-size
Date: Tue, 25 Oct 2022 14:47:05 +0000 (GMT) [thread overview]
Message-ID: <20221025144705.55E51385702E@sourceware.org> (raw)
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a2267dbfc9e1dd955f78561c40f00afa9ddbe619
commit a2267dbfc9e1dd955f78561c40f00afa9ddbe619
Author: Michael Matz <matz@suse.de>
Date: Thu Oct 20 16:06:57 2022 +0200
x86-64: Use only one default max-page-size
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 only 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.
Diff:
---
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
reply other threads:[~2022-10-25 14:47 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20221025144705.55E51385702E@sourceware.org \
--to=matz@sourceware.org \
--cc=bfd-cvs@sourceware.org \
/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).