ld: Question about the string merging feature

[Michael Matz]

Hello,

On Thu, 13 Jun 2024, Ludwig Rydberg wrote:

> >> My question is what to expect here?
> > 
> > My understanding is that by permitting merging, you give up certain
> > expectations you could normally validly have as to placement in the final
> > binary. This would become more obvious if you had some cases in your
> > example where strings could actually be merged. The (true) merging that
> > then would happen would already break your assumptions. Since making such
> > assumptions isn't correct anyway when merging is permitted, the new
> > logic may as well move stuff around further (presumably all into the 1st
> > .rodata, i.e. resulting from *foo*.o(.*data*) in your linker script).
> > 
> >> Was this change intended and part of
> >> the work with the "Faster string merging" feature?
> > 
> > It may not have been "intended", but I suppose such side effects were at
> > least to be expected.
> 
> Ok, I understand.
> Thanks for shedding some light on it and for the quick response.

And to expand a little on that: yes, the old code made it so that 
"unmerged" strings ended up in their original place.  It did so more or 
less as side-effect of how the algorithm worked, not so much by design. 
The new code doesn't try to retain this behaviour as it couldn't have been 
relied upon anyway: as soon as an (possibly completely unrelated, perhaps 
from a newer static archive library) object file would have been linked 
that made something mergable those parts would then randomly have been 
included in the merged-stuff lump.

So the new code does away with that and simply regards all mergable input 
blobs (or a certain property) as being transferred completely into a 
single mergable output blob (which is conceptually attached to the first 
seen mergable input blob for sections assignment purposes).

So, yeah, what you see is expected.


Ciao,
Michael.