[RFC 19/28] [SFrame-V3] sframe: gas: translate specific CFI directives for SFRAME_FDE_TYPE_FLEX_TOPMOST_FRAME

[Jens Remus]

On 12/16/2025 7:48 AM, Indu Bhagat wrote:
> On 12/15/25 6:10 AM, Jens Remus wrote:
>> On 12/9/2025 10:07 AM, Indu Bhagat wrote:
>>> This patch updates the SFrame generation in GAS to translate specific CFI
>>> directives into the new SFrame V3 FDE type: SFRAME_FDE_TYPE_FLEX_TOPMOST_FRAME.
>>>
>>> The primary goal is to support code patterns where:
>>>    - the Canonical Frame Address (CFA) is not defined by a simple offset
>>>      from the Stack Pointer (SP) or Frame Pointer (FP), or where the CFA
>>>      rule involves a dereference. Such patterns are generated by compilers
>>>      for stack realignment (e.g., DRAP on x86_64, or when mixing legacy
>>>      codes that keep 4-byte stack alignment with modern codes that keep
>>>      16-byte stack alignment for SSE compatibility).
>>>    - the Frame Pointer is not defined by a simple offset from the CFA,
>>>      but may even involve another register and/or dereferencing.
>>>    - the Return Address is not defined by a simple offset from the CFA,
>>>      but may even involve another register and/or dereferencing.
>>>
>>> Support for non-SP/FP based CFA: Update sframe_xlate_do_def_cfa () and
>>> sframe_xlate_do_def_cfa_register () to detect when a non-SP/FP register
>>> is used for the CFA.
>>>
>>> Support for CFA expressions: A vital part of supporting the
>>> above-mentioned cases on AMD64 is support for CFA expressions.  Add
>>> sframe_xlate_do_escape_cfa_expr () to parse simple
>>> DW_CFA_def_cfa_expression sequence in .cfi_escape.
>>>
>>> Support for FP expressions: Update sframe_xlate_do_escape_expr () to
>>> handle DW_CFA_expression involving `DW_OP_breg6` (rbp) on AMD64,
>>> allowing for tracking of the Frame Pointer when it is saved with a
>>> dereference rule in the DRAP pattern.
>>>
>>> The "support" for both CFA expressions and FP expressions is quite
>>> minimal, and is tailored to the most commonly seen occurences generated
>>> by GCC.
>>>
>>> Add a helper sframe_fre_reg_encodable_p () to verify if a DWARF register
>>> number can be encoded in the limited bits (5 bits) available in the
>>> SFrame format.
>>>
>>> This functionality is currently implemented only for the
>>> SFRAME_ABI_AMD64_ENDIAN_LITTLE ABI.  Support for other ABIs may be added
>>> without format version bump, as the necessary specification changes will
>>> already be in place.
>>
>>> diff --git a/gas/gen-sframe.c b/gas/gen-sframe.c
>>
>>> +/* Whether the provided (DWARF) reg number REG is encodable in the upper 5 bits
>>> +   available in the offset.  */
>>> +
>>> +/* FIXME - OKay to use DWARF register numbers ?  Should work for AMD64 and
>>> +   s390x IIUC.  */
>>
>> For s390x (s390 64-bit) that is ok:
>> s390x currently only supports saving of FP/RA in general registers 0-15
>> (DWARF register numbers 0-15) and floating-point registers 0-15 (DWARF
>> register numbers 16-31).
>>
>> But in general I thought SFrame V3 would encode the reginfo/regdata as
>> one "offset", so it could grow to 16- or 32-bit, or is that not the case?
>> Then why not allow 29 bits (= 32 - 3) right away?
>>
> 
> In SFrame, all FRE offsets are same sized data.  So if we enforce a
> minimum of say 16-bit for register data, all SFrame FREs for flexible
> FDE type will need to be 16 bits.

I would not enforce any minimum.  The logic that determines the FRE
"offset" size should account for the register number.  In addition of
factoring in .cfa_offset, .fp_offset, and .ra_offset it would also
have to factor in .cfa_base_reg << 3 , .fp_reg << 3, and .ra_reg << 3.

> I thought about using an ABI-specific minimum width, which would work
> well.  This information need not be carried in each section, it can
> just be a part of the specification.
> 
>>> +
>>> +static bool
>>> +sframe_fre_reg_encodable_p (unsigned int reg)
>>> +{
>>> +  /* A 5-bit field can hold values from 0 up to (2^5 - 1) = 31.  */
>>> +  return (reg <= 31);
>>> +}
>>
>> Btw. I strongly encourage to change the terminology from "offsets" and
>> "offset1" and "offset2" to CFA/FP/RA tracking information, which can be
>> offsets (in case of regular FREs) or tracking_info + offset (in case of
>> FLEX_TOPMOST_FRAME), where the tracking_info encodes an optional
>> register and dereference.  That would work well with fde_info and fre_info?
>>
> 
> Yeah, I agree with "offsets" being a misnomer.
> 
> How about "LocationItem" or LocItem ? Because this data actually gives
> the location information for each of CFA/FP/RA: whether it is a register,
> or CFA absed offset, or REG/OFFSET pair.

Either that or "tracking info".  But offset is meanwhile just confusing.

> The change is going to be significant though (code comments, APIs, spec
> terminology).  Does anyone else have word of advice for or against such
> a change ?

While it is a lot of effort it would be beneficial in the long term.
Maybe it could be done in smaller steps?

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/