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

[Indu Bhagat]

On 3/24/25 9:08 AM, Michael Matz wrote:
> Hello,
> 

Hi,

Thanks for chiming in.

> On Mon, 24 Mar 2025, Jan Beulich wrote:
> 
>>> 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.
>>

SFrame merging is not optional.  If simply concatenated, the output 
SFrame section is not really correct SFrame information.  As per 
specification, there is one SFrame Header, N SFrame FDEs (function 
descriptor entrues), M SFrame FREs (frame row entries).  The SFrame FDE 
and FRE are different semantic units of the stack trace data.

>> 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.
> 
> Yes, a separate ELF section type would have been definitely proper here
> :-/
> 

What would such a ELF section type want to indicate?  That this is a say 
SHT_SFRAME ?  I am thinking anything more generic to accommodate (in 
hindsight), say .eh_frame , or .ctf (or .BTF and more in future), in one 
section flag will not work, as the merging semantics for each of these 
sections are quite different:

   - .eh_frame uses relocations (PC-rel)
   - .ctf does not use relocations but the types are de-duplicated when 
merging.
   - .BTF, IIUC, will need some relocations.  And similar to .ctf, there 
will be de-duplication too.