[PATCH] ld: entry size and merge/strings attributes propagation

[Cary Coutant]

> The section in question is .rodata.  Some tools don't work with non-zero
> sh_entsize on .rodata.   How should a tool interpret non-zero sh_entsize
> on these special sections?

Well, that's unusual. By setting sh_entsize on the section, the
compiler (or assembler) is claiming that the section has a table of
fixed-size records. Perhaps that's true, but it seems unlikely. Maybe
it's the case for one single contribution to the .rodata section, but
it's highly unlikely to remain true for the combined output section.
The question is who is the compiler trying to inform about the
fixed-size nature of the contents? The linker doesn't care, so it's
not really its job to validate or enforce. Perhaps there's a pre-link
or post-link tool that could make use of that information. More
likely, I wonder if someone misinterpreted the ELF spec in the other
direction to infer that if a section has a table of fixed-length
records, then it *must* set sh_entsize. That's no more true than your
assertion that it must be 0 except for merge sections.

Anyway, I suppose your question is what is the linker supposed to do
with it? If the linker encounters multiple .rodata sections, all with
the same sh_entsize, then just preserve the value. If they don't all
have the same value, you have two choices: set the output sh_entsize
to 0, or refuse to combine sections with mismatched values. I'd
suggest the former.

What other tools are not working because of this? Why would a tool
care what the sh_entsize value is on a section that has no special
significance to that tool? (Answer: it shouldn't.)

-cary