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

[Michael Matz]

Hello,

On Tue, 19 Aug 2025, H.J. Lu wrote:

> The section in question is .rodata.  Some tools don't work with non-zero 
> sh_entsize on .rodata.

Define "some tools", and define "don't work".  Those tools need 
fixing then.

> How should a tool interpret non-zero sh_entsize on these special 
> sections?

How is .rodata special?  entsize!=0 doesn't have much meaning for (e.g.) 
the link editors default section handling (cat'ing them together), or in 
fact for most of the usual binary tools, at least not beyond the fact that 
it should divide the sections size and be compatible with alignment.  But 
it may have meaning for something else, maybe for the program containing 
them.

As QoI issue, if all input sections have the same entsize then it'd 
be nice if the output section has that as well.  Obviously if the inputs 
disagree on the entsize the entsize of the output isn't known anymore and 
must be set to zero (or, if the inputs were in some way special, this 
coule be diagnosed).

For real special sections (e.g. symbol tables), the entsize does have 
meaning (and should perhaps be checked for consistency), but then whatever 
tools handle them already do handle them specially.

So tools should handle entsize "naturally": try to conserve it from inputs 
to outputs, and zero them out if that's not obviously possible.  Any 
special sections that don't have linker-cat semantics (e.g. MERGE, STRING 
sections, or non SHT_PROGBITS): those may of course specify additional 
constraints on entsize, which the tools then have to obey.


Ciao,
Michael.