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

[Fangrui Song]

On 2022-10-20, H.J. Lu via Binutils wrote:
>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.

Thanks.  I like consistent max-page-size=4096 for x86.

(I'll update
https://maskray.me/blog/2020-11-15-explain-gnu-linker-options "-z separate-code" when this patch lands.)