[RFC 4/4] ld: bfd: sframe: fix incorrect r_addend in RELA entries

[Jan Beulich]

On 24.03.2025 16:53, Michael Matz wrote:
> Hello,
> 
> On Fri, 14 Mar 2025, Jan Beulich wrote:
> 
>>> Note how the SFrame FDEs in the output section are placed at the 
>>> beginning of the output section.
>>>
>>> This is in contrast to EH_Frame where the CIE/FDE _as_a_single_unit_is 
>>> simply placed at an offset in the output section.  In SFrame the stack 
>>> trace data is split, with there being ONE SFrame FDE + N SFrame FREs 
>>> per function.
>>
>> Hmm, this is pretty odd imo. There should have been two section kinds (or
>> maybe even three, seeing that the SFrame headers end up fully folded in
>> the diagram above), which would be combined only when linking final
>> binaries.
> 
> That's true.  But overall this section rewriting by the link editor 
> (instead of just cat-ing selected individual sections together into one 
> output blob) is not something new.  string section merging is doing the 
> same on a smaller scale, and relocations into those need to be rewritten 
> in a similar vain, and in particular by understanding the section 
> content/format (in string sections that's of course very simple, but it's 
> still interpreting the section content).
> 
> I don't know if the sframe merging is optional or not (like string merging 
> is), to retain normal reloc behaviour it better should be (so that, as you 
> say, unaware tools would still do the right thing).  But either way, 
> there's precedent for reloc-mangling based on section content.

Yes and no. SHF_MERGE (alone or together with SHF_STRING) properly describes
the contents, as to what needs doing to it when linking. Whereas here each
tool needs to learn what to do about sections of a certain, special name,
which aren't even otherwise recognizable or distinguishable.

Jan