This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 08/16/2018 09:16 PM, Mark Wielaard 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=23535I 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 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.
The binaries are already out there and will be around for a while, even if we reduce the alignment now. So generic ELF parsers need to cope with these binaries anyway.
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.
There are no 8-byte word ELF notes on GNU systems, that's an HP-UX feature. The new 8-byte-aligned notes still have a four-byte header.
But like you, I don't yet see the value of the 8-byte alignment. We could decide that the current gold behavior is valid, fix glibc, and move on.
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |