https://sourceware.org/bugzilla/show_bug.cgi?id=33851
--- Comment #10 from Jan Beulich <jbeulich at suse dot com> ---
(In reply to Alan Modra from comment #9)
> .note.GNU-stack differs from other note sections
> - it has zero size, and thus none of the entries that SHT_NOTE sections have
> as specified in the sysV ELF ABI, instead conveying information via its
> presense and its sh_flags,
One of its flags only, really. Other flags are (perhaps bogusly?) ignored.
Perhaps it (bogusly) having non-zero size would also be ignored.
Its conveying of information is entirely independent of its type, aiui.
Technically (if its name wasn't in conflict with .note.*) it could as well have
been SHT_NOBITS, I suppose. Which ultimate output section it contributes
<nothing> to really shouldn't matter for its purpose.
> The section itself does not "hold information".
> Yes, I recognize that we must allow zero size for some other sections that
> the spec says "hold information", but for example a zero size SHT_RELA in a
> relocatable object could be completely removed without losing information.
Yet removal of zero-size sections isn't something you can do "blindly". For
SHT_REL{,A} that may indeed be okay, as their purpose is well-known.
> - it doesn't result in a PT_NOTE program header in a final linked object as
> other SHT_NOTE sections do.
That depends on the linker script used, doesn't it?
> BTW, .note.GNU-split-stack and .note.GNU-no-split-stack are similar to
> .note.GNU-stack in that they are emitted by gcc as zero size SHT_PROGBITS.
I did spot these, yes, just that in binutils the only references live under
gold/. Therefore I kind of expect gcc to only use these when the configured
linker is gold.
The bigger underlying problem is the solely name-based treatment when linker
scripts come into play. But of course ELF having section types is being ignored
in many other places, too, and (purely / mainly) name-based approaches are used
instead. Yet as a result names need to be chosen a little carefully, and they
need to then match certain conventions in order to at least not conflict with
the use of section types.
--
You are receiving this mail because:
You are on the CC list for the bug.
