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

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

[Michael Matz]

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

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

[H.J. Lu]

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.

Re: 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.)

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

[Michael Matz]

Hello,

On Thu, 20 Oct 2022, Fangrui Song wrote:

> > > bfd/
> > >         * elf64-x86-64.c (ELF_MAXPAGESIZE): Don't depend on
> > >         DEFAULT_LD_Z_SEPARATE_CODE.
> > 
> > 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.)

Now there as a2267dbfc9e1dd955f78561c40f00afa9ddbe619 .


Ciao,
Michael.