[V3 10/36] [SFrame-V3] include: libsframe: bfd: gas: testsuite: support for signed 64-bit offset in SFrame FDE

[Indu Bhagat]

On 1/15/26 11:52 PM, Jan Beulich wrote:
> On 13.01.2026 12:12, Indu Bhagat via Binutils wrote:
>> --- a/include/sframe.h
>> +++ b/include/sframe.h
>> @@ -247,9 +247,9 @@ typedef struct sframe_func_desc_entry_v2
>>   
>>   typedef struct sframe_func_desc_entry_v3
>>   {
>> -  /* Function start address.  Encoded as a signed offset, relative to the
>> -     beginning of the current FDE.  */
>> -  int32_t sfde_func_start_address;
>> +  /* Offset to the function start address.  Encoded as a signed offset,
>> +     relative to the beginning of the current FDE.  */
>> +  int64_t sfde_func_start_offset;
>>     /* Size of the function in bytes.  */
>>     uint32_t sfde_func_size;
> 
> I realize I'm late now with comments, seeing that the whole series was
> committed, but still: While the v2 cover letter mentions mitigations
> towards the size increase, using 64 bits uniformly still feels odd to
> me. Those other size reductions are beneficial indepenently, and for
> not overly large binaries it would imo be beneficial if they could get
> away with just 32 bits of storage per function start offset. (Likely
> this was discussed before,
> 

Allowing 32bits per function start offset was given a thought. (In fact 
initially I had implemented the 64-bit func start offset usage enabled 
only via an explicit --gsframe64)

I think the main concern was support for static links.  ld will not be 
able to mix input objects where some have 32-bit func start offset and 
others have 64-bit func start offset.  Linker would need to "upgrade" 
32-bit relocations to 64-bit if needed in that case, something that we 
thought wouldnt be easy/possible/recommended to do.

This means if we then resolve the above as ld erroring out when mixing 
objects with 32-bit with 64-bit function start offsets, it would be 
painful for those users who use static links with SFrame enabled.

What do you think ?