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

[H.J. Lu]

On Wed, Aug 20, 2025 at 7:22 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> 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.

The output .rodata section has all kinds of data.  Some input sections
may contain strings which have non-zero sh_entsize.  It doesn't make
sense to set the output sh_entsize to some sh_entsize value in an input
string section.

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



-- 
H.J.