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

[Michael Matz]

Hello,

On Mon, 24 Mar 2025, Indu Bhagat wrote:

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

I see.  That's not ideal, but workable.  Ideally the format would have 
been designed such that a trivial link editor cat-ing the relevent 
sections would create something working (albeit larger than necessary), 
and the clever merging would merely be an optimization.  So, ...

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

... something that would keep the FRE and FDE entries in separate sections 
in the .o files, with appropriate cross-section relocation to refer to 
each other.  The final linked format (where segments, not sections, 
matter) could still specify that they need to be placed next to each other 
(all FDEs, then all FREs).  Alas, the ship has sailed, so we'll need to 
make do :)

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

Yes.  Basically every section that has structured content that a link 
editor usefully (or necessarily as here) needs to parse (and mangle) to do 
its thing should have a separate SHT_ type.

The mental model for ELF and any extensions of it should be that section 
names don't matter: when one designs something for the ELF file format, 
and a thought experiment that nulls all section names from input .o files 
reveals that something doesn't quite work or is awkward to do for the link 
editor, then the design isn't yet complete.  Every time someone does a 
strcmp between sh_name and a const string a kitten dies!

SHT_PROGBITS should be reserved for the simple "cat contents after 
applying relocs" semantics (the flags will say into which segment to cat 
the contents).  Of course, that ship also has sailed for many things in 
existence, but it would be Really Nice if new improvements would follow 
that model (again).

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

Different structured content would need different section types.  
There are 0x60000000 of them and we've used 20.  (and there are more in 
the OS and arch range, and then even more after all those).  Section flags 
are fewer, those shouldn't be used lightly, but section types: go wild.

eh_frame is in the middle ground actually: SHT_PROGBITS does work, one can 
simply cat all content and the result "works".  It's not optimal, because 
such simple link editor wouldn't build up eh_frame_hdr (because it can't 
inspect the "unstructured" content), and hence it's slow to access at 
runtime, but it works.  It would have been better if it had its own 
section type, but that's definitely too late now.

Perhaps its not too late for ctf and friends, I don't know.

(But again: it's not the specifics of relocations that should influence 
the decision to create a new section type, it's the structure of content 
of sections and the need for link editors to peek into it that wants a 
section type.  Peeking into content of course might mean that relocations 
need to be taken into account, including rewriting them if the content 
isn't just peeked into but actively changed)


Ciao,
Michael.