public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Fangrui Song <i@maskray.me>,  Binutils <binutils@sourceware.org>
Subject: Re: [PATCH] elf: Set p_align to the common page size if possible
Date: Mon, 20 Dec 2021 20:51:50 +0100	[thread overview]
Message-ID: <87wnjzdpgp.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <CAMe9rOrLPNXPgARf8q-OR0hFw_vDwi+MVkAk2o+DuaaKWrap=w@mail.gmail.com> (H. J. Lu's message of "Mon, 20 Dec 2021 11:31:00 -0800")

* H. J. Lu:

> On Mon, Dec 20, 2021 at 11:25 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * H. J. Lu:
>>
>> > On Mon, Dec 20, 2021 at 10:51 AM Florian Weimer <fweimer@redhat.com> wrote:
>> >>
>> >> * H. J. Lu:
>> >>
>> >> > We need to set larger p_align > sh_addralign for huge page executables.
>> >> > My current algorithm to decide if p_align should be used as the maximum
>> >> > page size for objcopy is
>> >> >
>> >> > static bool
>> >> > elf_is_p_align_valid (bfd *abfd)
>> >> > {
>> >> >   unsigned int i;
>> >> >   Elf_Internal_Phdr *segment;
>> >> >   unsigned int num_segments;
>> >> >   const struct elf_backend_data *bed = get_elf_backend_data (abfd);
>> >> >   bfd_size_type maxpagesize = bed->maxpagesize;
>> >> >   bfd_size_type commonpagesize = bed->commonpagesize;
>> >> >
>> >> >   if (commonpagesize == maxpagesize)
>> >> >     return true;
>> >> >
>> >> >   /* When the common page size != the maximum page size, p_align may
>> >> >      be set to the common page size while segments are aligned to
>> >> >      the maximum page size.  In this case, the input p_align will be
>> >> >      ignored and the maximum page size will be used to align the output
>> >> >      segments.  */
>> >> >   segment = elf_tdata (abfd)->phdr;
>> >> >   num_segments = elf_elfheader (abfd)->e_phnum;
>> >> >   for (i = 0; i < num_segments; i++, segment++)
>> >> >     if (segment->p_type == PT_LOAD
>> >> >         && (segment->p_align != commonpagesize
>> >> >             || vma_page_aligned_bias (segment->p_vaddr,
>> >> >                                       segment->p_offset,
>> >> >                                       maxpagesize) != 0))
>> >> >       return true;
>> >> >
>> >> >   return false;
>> >> > }
>> >> >
>> >> > It should cover all cases.
>> >>
>> >> Will this switch from 64K to 4K on POWER and AArch64?  I think this will
>> >
>> > It will set p_align to ELF_COMMONPAGESIZE.  It glibc doesn't support
>> > p_align == ELF_COMMONPAGESIZE, the ELF_COMMONPAGESIZE
>> > is wrong.
>>
>> Hmm.
>>
>> bfd/elf32-arm.c:#define ELF_COMMONPAGESIZE              0x1000
>> bfd/elf32-arm.c:#undef  ELF_COMMONPAGESIZE
>> bfd/elf32-arm.c:#undef  ELF_COMMONPAGESIZE
>> bfd/elf32-arm.c:#define ELF_COMMONPAGESIZE              0x1000
>> bfd/elf32-ppc.c:#define ELF_COMMONPAGESIZE      0x1000
>> bfd/elf64-ppc.c:#define ELF_COMMONPAGESIZE      0x1000
>> bfd/elfnn-aarch64.c:#define ELF_COMMONPAGESIZE          0x1000
>>
>> This looks problematic.
>>
>> We have a sed patch in binutils.spec to change ELF_COMMONPAGESIZE:
>>
>> # On ppc64 and aarch64, we might use 64KiB pages
>> sed -i -e '/#define.*ELF_COMMONPAGESIZE/s/0x1000$/0x10000/' bfd/elf*ppc.c
>> sed -i -e '/#define.*ELF_COMMONPAGESIZE/s/0x1000$/0x10000/' bfd/elf*aarch64.c
>> sed -i -e '/common_pagesize/s/4 /64 /' gold/powerpc.cc
>> sed -i -e '/pagesize/s/0x1000,/0x10000,/' gold/aarch64.cc
>
> This should be fixed in binutils upstream.

I've brought this up internally.  To me it looks like binutils is fine,
we tried to workaround the strict p_align stricting in glibc (bug 28688)
for some reason.  This was fifteen years ago, so we'll see if we can
still figure out why we did it this way.

Thanks,
Florian


  reply	other threads:[~2021-12-20 19:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-15 16:32 H.J. Lu
2021-12-16  8:52 ` Fangrui Song
2021-12-16 14:33   ` H.J. Lu
2021-12-20 16:36   ` Florian Weimer
2021-12-20 18:39     ` H.J. Lu
2021-12-20 18:51       ` Florian Weimer
2021-12-20 18:59         ` H.J. Lu
2021-12-20 19:25           ` Florian Weimer
2021-12-20 19:31             ` H.J. Lu
2021-12-20 19:51               ` Florian Weimer [this message]
2021-12-20 15:50 ` H.J. Lu
2021-12-22  8:57   ` Alan Modra
2021-12-22 14:38     ` [PATCH v2] elf: Set p_align to the minimum " H.J. Lu
2021-12-25  1:03       ` Alan Modra
2021-12-25  2:50         ` H.J. Lu
2021-12-25  3:04           ` Alan Modra
2021-12-25  3:08             ` H.J. Lu
2021-12-25  3:58               ` Alan Modra
     [not found]   ` <f64b9fb3-7d2d-7ff3-a8f6-795292af6744@redhat.com>
     [not found]     ` <CAMe9rOrvGXXEJAESEgTbhgQJee__Ak9+OvFwzWa0Nxv+m+OjLg@mail.gmail.com>
2022-01-05 10:17       ` [PATCH] elf: Set p_align to the common " Nick Clifton

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=87wnjzdpgp.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=i@maskray.me \
    /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).