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

[Indu Bhagat]

On 3/31/25 11:08 PM, Jan Beulich wrote:
> 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.
> 

Yeah, an entry in NEWS should be added, one way or another (see the next
response on your question about adopting Scheme#B in spec).


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

LLVM implementation of SFrame is in the works.

Yes, I did go through the exercise of seeing what it looks like to adopt
Scheme#B in GNU Binutils and impact on stack tracer.  High level summary:

- Impact on stack tracer itself seems to be within reason.  Stack tracer
   routines looking up FDE/FRE need to be adapted to perform the check 
for FDE
   start PC a bit differently, but it looks doable.

- Impact on GNU binutils has been partially evaluated, but seems doable.
   + GAS, ld impact looks OK.  Patch 1 and Patch 4 in the current series 
will
     not be needed.
   + There need to be some "fixes" in the SFrame generation for the .plt*
     sections.  This is just because SFrame for these sections is manually
     created.

- Impact on libsframe (was attempted, but now I have second thoughts).
   + sorting of FDEs in sframe_encoder_write_sframe () needs fixing. 
One cannot
     just sort the offsets in Scheme#B without some pre-processing as the
     distances are not from the same anchor.
   + adapting the sframe_find_fre () and its stack of routines for Scheme#B.
     libsframe does malloc to bring a sort-of-decoded SFrame into its 
memory.
   + On my first attempt, it did look like it would bring some extra
     work/complexity to libsframe, to the extent that it seemed Scheme#B did
     not appear to be a natural fit.   But since the sending of the this 
series,
     I have been having second thoughts.  Perhaps I should give it one more
     unprejudiced try.

Thanks
Indu