x86-64: Use only one default max-page-size

H.J. Lu hjl.tools@gmail.com
Thu Oct 20 17:01:15 GMT 2022
On Thu, Oct 20, 2022 at 7:42 AM Michael Matz <matz@suse.de> 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.


More information about the Binutils mailing list