[PATCH] gold: Place .note.gnu.property section before other note sections

[Ian Lance Taylor]

On Tue, Oct 26, 2021 at 4:09 PM Cary Coutant via Binutils
<binutils@sourceware.org> wrote:
>
> >         PR gold/28494
> >         * layout.cc (Layout::create_note): Set order to ORDER_PROPERTY_NOTE
> >         for the .note.gnu.property section.
> >         * layout.h (Output_section_order): Add ORDER_PROPERTY_NOTE.
>
> I'd prefer something more general, but it would be considerably more
> involved. Ideally, we'd recognize which sections would be broken by
> internal padding (like SHT_NOTE sections, but also perhaps others),
> and we could set the "must sort attached input sections" flag, then
> sort the input sections so that 8-byte-aligned sections always come
> first.
>
> This is OK, but it's a reluctant OK.
>
> I'm telling myself that this treatment is more compatible with the
> notion that these particular SHT_NOTE sections really ought to be
> SHT_GNU_PROPERTY sections, and would go into a PT_GNU_PROPERTY
> segment. Except for the SHT_ and PT_ names, this is probably how we
> would have handled it in that alternate universe.

I think the problem with the approach here is that it only works for
one particular note section.  Other note sections can introduce
similar problems.  Given the current handling of p_align in PT_NOTE
segments, I think we need to separate SHT_NOTE sections with 4 byte
alignment and SHT_NOTE sections with 8 byte alignment.  That is, I
think this patch is a step in the right direction, but it keys off the
wrong thing.

Right now if we see a SHT_NOTE section with 4 byte alignment, then one
with 8 byte alignment, then one with 4 byte alignment, we can wind up
with overlapping PT_NOTE segments.  And we won't necessarily be able
to parse the notes in the 4 byte PT_NOTE segment, because it will
depend on the position of the interior SHT_NOTE sections with 8 byte
alignment.

Ian