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

[H.J. Lu]

On Wed, Aug 20, 2025 at 7:17 AM Michael Matz <matz@suse.de> wrote:
>
> 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

https://sourceware.org/bugzilla/show_bug.cgi?id=33291

> fixing then.

When someone updates binutils, all of a sudden eu-strip stops working.
Is this a good idea? I can understand changing sh_entsize on some new
sections.  But changing it on existing special sections is a bad idea.

> > 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.



-- 
H.J.