public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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.

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