Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold

[Mark Wielaard <mark at klomp dot org>]

On Thu, Aug 16, 2018 at 12:36:34PM -0700, H.J. Lu wrote:
> On Thu, Aug 16, 2018 at 12:16 PM, Mark Wielaard <mark@klomp.org> wrote:
> > On Thu, Aug 16, 2018 at 04:21:05PM +0200, Florian Weimer wrote:
> >> On 08/16/2018 03:39 PM, H.J. Lu wrote:
> >> > glibc only discards 4-byte aligned NT_GNU_PROPERTY_TYPE_0 note
> >> > since NT_GNU_PROPERTY_TYPE_0 note follows gABI.  If gold
> >> > generates 4 byte alignment, it is a gold bug.
> >>
> >> I filed: https://sourceware.org/bugzilla/show_bug.cgi?id=23535
> >
> > I don't think this is a bug in gold, but one in ld:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=22749
> >
> > In the GNU abi all ELF Notes are arrays of 32bit words
> > (and so 4-byte aligned). This is the same for most other
> 
> That is not true.  NT_GNU_PROPERTY_TYPE_0 note is
> 8 byte aligned in 64-bit ELF.

Which is the bug we are trying to fix, right?
The issue with that note is that ld generates it with 32bit words,
but with extra padding to make it 8-byte aligned. That makes it
not confirm to the GNU abi and also not to the gabi. It causes all
ELF Note parsers to have to be adjusted. And since there are also
normal GNU abi ELF Notes without the extra padding it causes extra
sections and segments to be created because the alignment differs.
It seems simpler to just fix ld so that glibc can use a normal ELF
note parser for all ELF Notes, than to propagate that bug to other
linkers.

> > ELF systems. Making the ELF Notes fields 64bit words (and
> > so 8-byte aligned) in ELFCLASS64 would indeed be what gabi
> > literally says, but not what GNU systems, and others, follow.
> >
> > Having a mix of 4-byte words and 8-byte words ELF Notes
> > in the same ELF file seems unnecessarily confusing and
> > introduces extra segments and sections.
> >
> > Cheers,
> >
> > Mark
> 
> 
> 
> -- 
> H.J.