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

[Jan Beulich]

On 16.01.2026 09:46, Indu Bhagat wrote:
> 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.

Why would that be? Can't each struct instance flag what width it uses?

Jan