x86-64: Use only one default max-page-size
authorMichael Matz <matz@suse.de>
Thu, 20 Oct 2022 14:06:57 +0000 (16:06 +0200)
committerMichael Matz <matz@suse.de>
Tue, 25 Oct 2022 14:41:26 +0000 (16:41 +0200)
commita2267dbfc9e1dd955f78561c40f00afa9ddbe619
tree6fcd33fbabad2234b52cf85f844d8bc028a254dd
parent7699dfc8d5896556e700bd6cb36d76dd43252e98
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.
bfd/elf64-x86-64.c