[PATCH 1/4] gas: ld: sframe: FDE func start address is from start of section

[Jan Beulich]

On 31.03.2025 20:52, Indu Bhagat wrote:
> In SFrame V2, the start PC in the SFrame function descriptor entry is a
> 32-bit signed integer (sfde_func_start_address) which is meant to
> indicate the start PC of the function.  According to the specification,
> it intends to hold the offset of the start PC of the function from the
> _start_of_the_SFrame_section_.  This value can then be used by
> stacktracers to simply do:
> 
>    sframe_find_fre (pc - sframe_vaddr)
> 
> when looking up SFrame stack trace data corresponding to the program
> counter (pc).
> 
> In the current implementation, however, GAS is actually emitting a
> PC-relative RELA such that sfde_func_start_address is the offset of the
> start PC of the function from the _start_of_the_SFrame_FDE_.  ld.bfd was
> then fixing up the value by adjusting the final values by r_offset (and
> hence hiding the issue).  Fix GAS to correcly emit the SFrame section as
> per specification; and fix sframe merging routines in the linker to do
> the right thing.
> 
> Similarly, change the "relocated value" manually put into the SFrame FDE
> for plt* sections in _bfd_x86_elf_finish_dynamic_sections ().  While at
> it, keep the comments and the commented out code (for debugging) updated
> as well.
> 
> This is not a specification change, but is necessary for fixing
> relocatable links with SFrame.  ET_DYN, ET_EXEC binaries are unaffected.

How are object files created by one gas version (with or without this
change) going to work with the opposite ld version? The NEWS entry from
when SFrame support was introduced doesn't indicate it's experimental,
so imo interoperability is of concern. If that's impossible to deal with,
the very minimum would be to add NEWS entries for each affected
component indicating the caveat.

Was the alternative considered, of making the spec match the
implementation? Of course almost certainly that's an option only if GNU
binutils were the only known producer/consumer of this data.

Jan