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

[Michael Matz]

Hello,

On Wed, 20 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.

That is just broken handling (in binutils) of input inconsistency (that 
seemingly is addressed by the patches in that PR): if one 
of the inputs has zero entsize, then that means "unknown", not "unset".  
It can't be upgraded to some non-zero entsize (claiming the entsize now 
magically is known), just because other input sections contain non-zero 
entsizes.

So, a .rodata output that consists of a entsize=0 .rodata, and entsize!=0 
.strings/.const.data must have entsize=0.

But that is orthogonal to the question if a .rodata (or anything else) can 
or can not have entsize!=0 at all.  It _can_.


Ciao,
Michael.