https://sourceware.org/bugzilla/show_bug.cgi?id=28488
--- Comment #21 from Mark Wielaard <mark at klomp dot org> --- So we have 2 bugs, one for ld.bfd: NOTE 0x000338 0x0000000000400338 0x0000000000400338 0x000040 0x000040 R 0x8 NOTE 0x000378 0x0000000000400378 0x0000000000400378 0x000044 0x000044 R 0x4 GNU_PROPERTY 0x000338 0x0000000000400338 0x0000000000400338 0x000040 0x000040 R 0x8 Where: 07 [RO: .note.gnu.property] 08 [RO: .note.gnu.build-id .note.ABI-tag] 09 [RO: .note.gnu.property] So .note.gnu.property is covered twice. This is OK, but inefficient. It is not clear to me whether the first PT_NOTE is really needed at all (maybe backwards compatibility? but with what?) now that we have the GNU_PROPERTY. The bug for ld.gold is more severe: NOTE 0x0002b0 0x00000000004002b0 0x00000000004002b0 0x000030 0x000030 R 0x8 NOTE 0x00028c 0x000000000040028c 0x000000000040028c 0x000078 0x000078 R 0x4 Where: 05 [RO: .note.gnu.property] 06 [RO: .note.ABI-tag .note.gnu.property .note.gnu.build-id] There is no PT_GNU_PROPERTY. But both segment 05 and segment 06 cover .note.gnu.property, and segment 06 mixes notes using alignment 8 (causing different padding) and alignment 4 (.note.gnu.property is sandwiched between .note.ABI-tag and .note.gnu.build-id). No wonder eu-elflint cannot parse this PT_NOTE segment. -- You are receiving this mail because: You are on the CC list for the bug.
