[PATCH 1/2] libsframe: add new dump_sframe_reloc

[Jens Remus]

On 23.02.2025 01:56, Indu Bhagat wrote:
> On 2/21/25 8:21 AM, Jens Remus wrote:
>> On 21.02.2025 15:48, Indu Bhagat wrote:
>>> On 2/21/25 12:54 AM, Jan Beulich wrote:

...

>>>> Yet then why is further fixing up necessary? And how to you know how to
>>>> do the fixups, when you don't further look at the relocations coming from
>>>> the object.
>>>>
>>>
>>> IIUC, load_specific_debug_section () loads the debug section at address 0.  For PC-relative offsets, where the .text start address is also 0, load_specific_debug_section () calculates the S + A - P correctly.
>>>
>>> In SFrame FDE start address, we would like to indicate the function start address (hence, the PC-relative relocation).  In that respect, the function does assume that there is PC-relative relocation at the start of every FDE (for function start address); something I think is OK to do as this is baked into the format.
>>
>> I tried to wrap my head around it and came to the following conclusion:
>>
>> Each FDE sfde_func_start_address is assumed to have a PC-relative
>> relocation (e.g. PC32), which gets calculated as S + A - P.
>>
>> With S being the address of the function symbol, A = 0, and P being the
>> address of the field sfde_func_start_address the value of each FDE
>> sfde_func_start_address after relocation by load_specific_debug_section
>> is:
>>
> 
> (A = 0 is incorrect above).
> 
> S is 0 in the context of textual dump, A is the addend. E.g.  for an object where func1, func2, func3 are at .text + 0, .text + 30, and .text 0x40 respectively, we say:
> 
> Sym. Name + Addend
>    .text + 0
>    .text + 30
>    .text + 40

My bad!  The readelf output of the object file got me confused that the
symbol S value for .text would still be zero after final link, which it
of course won't.  I was looking into an issue with (function) pointer
equivalence where after final link the symbol value of SHN_UNDEF symbols
is either zero or the address of the canonical PLT entry.  That got me
on the wrong path.

With:

S = addr(.text)
A = offset(function)
P = addr(FDE) = addr(.sframe) + offset(FDE)

sfde_func_start_address
= S + A - P
= addr(.text) + offset(function) - (addr(.sframe) + offset(FDE))
= addr(.text) + offset(function) - addr(.sframe) - offset(FDE)

As .text and .sframe are treated as loaded at zero:

= offset(function) - offset(FDE)

This is why you need to add the FDE offset from .sframe section to fixup
sfde_func_start_address when dumping.


>> I guess the following in gas/gen-sframe.c, output_sframe_funcdesc()
>> implies that a PC-relative relocation is emitted?
>>
> 
> Yes.
> 
>>    /* Start address of the function.  */
>>    exp.X_op = O_subtract;
>>    exp.X_add_symbol = dw_fde_start_addrS; /* to location.  */
>>    exp.X_op_symbol = symbol_temp_new_now (); /* from location.  */
>>    exp.X_add_number = 0;
>>    emit_expr (&exp, addr_size);

Doesn't that mean that in the object file the FDE sfde_func_start_address
(when taking its relocation into account) is relative to the FDE and in
an executable or shared library (after final link) it is relative to the
.sframe section?

I think this should be mentioned in the SFrame documentation for
sfde_func_start_address, as that is unexpected given the current
description.


The following reduced excerpt from _bfd_elf_merge_section_sframe() seems
to apply the respective fixup when merging the .sframe sections:

   /* Get the SFrame FDE function start address after relocation.  */
   address = sframe_read_value (abfd, contents, r_offset, 4);
   address += (sec->output_offset + r_offset);
   func_start_addr = address;

r_offset is the FDE offset within the input .sframe section and
sec->output_offset the offset of the input .sframe section within
the output .sframe section.   So sec->output_offset + r_offset is
equivalent to the FDE offset from (output) .sframe section.

func_start_addr
= S + A - P + offset(FDE)
= addr(.text) + offset(function) - (addr(.sframe) + offset(FDE)) + offset(FDE)
= addr(.text) + offset(function)


Thanks and regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
+49-7031-16-1128 Office
jremus@de.ibm.com

IBM

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/