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

Michael Matz matz@suse.de
Mon Mar 24 15:53:49 GMT 2025


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.

> I now regret that I didn't look more closely at all of this when it was 
> first introduced.

(But yes, it would have been nice if this special handling hadn't been 
necessary :-/ )


Ciao,
Michael.


More information about the Binutils mailing list