From: "H.J. Lu" <hjl.tools@gmail.com>
To: Michael Matz <matz@suse.de>
Cc: binutils@sourceware.org, Alan Modra <amodra@gmail.com>
Subject: Re: x86-64: Use only one default max-page-size
Date: Thu, 20 Oct 2022 10:01:15 -0700 [thread overview]
Message-ID: <CAMe9rOpT8R6313MeKirqJjcVAE-2W1UnAQiRwLkbKH2s9KE8Og@mail.gmail.com> (raw)
In-Reply-To: <alpine.LSU.2.20.2210201432170.29399@wotan.suse.de>
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.
next prev parent reply other threads:[~2022-10-20 17:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-20 14:42 Michael Matz
2022-10-20 17:01 ` H.J. Lu [this message]
2022-10-20 17:35 ` Fangrui Song
2022-10-25 15:44 ` Michael Matz
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=CAMe9rOpT8R6313MeKirqJjcVAE-2W1UnAQiRwLkbKH2s9KE8Og@mail.gmail.com \
--to=hjl.tools@gmail.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=matz@suse.de \
/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).