Home Original page

[RFC 14/28] [SFrame-V3] include: gas: libsframe: add 8-bits of func_info2 for extensibility in FDE

Indu Bhagat indu.bhagat@oracle.com
Tue Dec 23 05:23:01 GMT 2025 
On 12/22/25 7:15 AM, Jan Beulich wrote:
> On 09.12.2025 10:07, Indu Bhagat via Binutils wrote:
>> --- a/include/sframe.h
>> +++ b/include/sframe.h
>> @@ -264,6 +264,13 @@ typedef struct sframe_func_desc_entry_v3
>>        ---------------------------------------------------------------------------------
>>        8        7             6                             5           4              0     */
>>     uint8_t sfde_func_info;
>> +  /* Additional information for stack tracing from the function:
>> +     - 8-bits: Unused.
>> +     -------------------------------------------------------------------------
>> +     |                            Unused                                     |
>> +     -------------------------------------------------------------------------
>> +     8        7         6                  5           4              0     */
>> +  uint8_t sfde_func_info2;
>>     /* Size of the block of repeating insns.  Used for SFrame FDEs of type
>>        SFRAME_FDE_TYPE_PCMASK.  */
>>     uint8_t sfde_func_rep_size;
> 
> Prior to patch 08 arrangements here guaranteed that the struct size would be
> a multiple of 4 bytes, thus - if its base was suitably aligned - 2- and 4-byte
> fields being easy to deal with no matter that ATTRIBUTE_PACKED was also used
> (and it's not quite clear to me why that was used). Patch 10 then restored
> this property, but now it looks to get permanently broken. If that's consensus
> among the parties interested in SFrame, so be it, but imo this would at least
> want calling out and then justifying in the description.
> 

In the patch series, between patch 08 (use uint16_t for num_fres of FDE) 
to 23 (split FDE into desc and attr), yes the alignment guarantees are 
broken.  This does mean some sanitizer runs may not be clean (Hmm, I 
still have pending TODO to check that the reading of sfda_func_num_fres 
is properly handled at unaligned boundary.)

That said, after patch 23: In SFrame V3, FDE is now split into the index 
and attributes.

The following being the index data structure:

typedef struct sframe_func_desc_entry_v3
{
   /* 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;
   /* Offset of the first SFrame Frame Row Entry of the function, 
relative to the
      beginning of the SFrame Frame Row Entry sub-section.  */
   uint32_t sfde_func_start_fre_off;
} ATTRIBUTE_PACKED sframe_func_desc_entry_v3;

And this for the attributes:

typedef struct sframe_func_desc_attr_v3
{
   /* Number of frame row entries for the function.  */
   uint16_t sfda_func_num_fres;
   /* Additional information for stack tracing from the function:
      - 4-bits: Identify the FRE type used for the function.
      - 1-bit: Identify the FDE type of the function - mask or inc.
      - 1-bit: PAC authorization A/B key (aarch64).
      - 1-bits: Unused.
      - 1-bit: Signal frame.  */
   uint8_t sfda_func_info;
   /* Additional information for stack tracing from the function:
      - 5-bits: FDE type.
      - 3-bits: Unused.  */
   uint8_t sfda_func_info2;
   /* Size of the block of repeating insns.  Used for SFrame FDEs of type
      SFRAME_FDE_TYPE_PCMASK.  */
   uint8_t sfda_func_rep_size;
} ATTRIBUTE_PACKED sframe_func_desc_attr_v3;

The attribute data is placed at the sfde_func_start_fre_off, i.e., in 
the FRE sub-section.  With no guarantees of alignment (like the other 
data in the FRE sub-section).

The above layout has the advantage that:
   a) its cleaner with separation between the index elements vs other data
   b) the index has better cache locality (by virtue of it being smaller 
than the layout in SFrame V2).
   c) As the format evolves, the guarantees of alignment for FDE index 
are easier to maintain.

This had been previously suggested and communicated in an earlier 
discussion on binutils mailling list 
https://inbox.sourceware.org/binutils/29b1f7b0-61ea-410c-8aca-d5dd6115e668@oracle.com/

I will add some of the above to the commit log of patch 23 perhaps.

Thanks
More information about the Binutils mailing list