[V2 18/36] [SFrame-V3] gas: sframe: output new FDE type SFRAME_FDE_TYPE_FLEX

[Indu Bhagat]

On 1/16/26 4:04 AM, Jens Remus wrote:
> On 1/13/2026 10:13 AM, Indu Bhagat wrote:
>> On 1/13/26 12:31 AM, Jens Remus wrote:
>>> On 1/13/2026 3:06 AM, Indu Bhagat wrote:
>>>> On 1/12/26 2:28 AM, Jens Remus wrote:
>>>>> Hello Indu, Jose, Steven, et al.,
>>>>>
>>>>> On 1/7/2026 9:42 AM, Indu Bhagat wrote:
>>>>>> This patch updates the routines for emission of the new FDE type
>>>>>> SFRAME_FDE_TYPE_FLEX in the SFrame output section.  The support for
>>>>>> generating these flex FDEs themselves is added in a subsequent commit.
>>>>>>
>>>>>> For flex FDE type, output_sframe_row_entry_offsets () emits two
>>>>>> offsets for RA tracking, irrespective of the ABI/arch, i.e.,
>>>>>> irrespecitve of whether RA-tracking is enabled.  This is because, for
>>>>>
>>>>> Please mention that only a single FP/RA padding "offset" is used when
>>>>> FP location info without RA location info is encoded.
>>>>>
>>>>>> flex FDE type, RA is allowed "non-standard" recovery rules,
>>>>>> e.g., RA = REG or RA = *(REG+offset).  In a follow-up patch, when
>>>>>> handling for .cfi_register RA, REG is added, emission code will be
>>>>>> patched up accodingly.
>>>>>
>>>>> TL;DR:  Recap of why a single padding offset of zero is acceptable.
>>>>>            Skip to stack tracer implications below.
>>>>>
>>>>> Regarding whether a single RA padding offset of zero (instead of two) is
>>>>> sufficient to represent FP without RA saved:
>>>>>
>>>>> reg_data = SFRAME_V3_FLEX_FDE_REG_ENCODE (0 /* regnum */, 0 /* deref_p */, 0 /* reg_p */)
>>>>>             = SFRAME_FRE_RA_OFFSET_INVALID
>>>>>             = 0
>>>>>
>>>>> We established that this encoding rules out to represent the CFI
>>>>> directive .cfi_val_offset RA, <offset> (means RA = CFA + <offset>) in
>>>>> SFrame V3 without any additional flag in reg_data.
>>>>>
>>>>> This would not be an issue for RA, as .cfi_val_offset specifies an
>>>>> address on the stack (as long as CFA points somewhere to the stack),
>>>>> which should never be valid for the return address.
>>>>> For FP this should not be useful either, as the FP value at entry
>>>>> should not be known and thus not be representable related to CFA.
>>>>> For SP, if SFrame would ever be extended to track SP, the only
>>>>> sensible rule should be the one from the CFA definition
>>>>> (e.g. CFA = SP at call site or CFA = SP at call site + 160 on s390x),
>>>>> which would not need to be explicitly encoded, as it is already
>>>>> implicitly assumed to unwind SP.
>>>>>
>>>>> If the need to represent .cfi_val_offset {SP|FP|RA} would still arise,
>>>>> the spare unused bit in reg_data could possibly be used.  It may be
>>>>> required after all, as .cfi_val_offset {SP|FP|RA}, <offset> encodes as:
>>>>>
>>>>>      reg_data = 0;
>>>>>      offset_data = <offset>;
>>>>>
>>>>
>>>> Currently, .cfi_val_offset {SP|FP|RA} is not handled for SFrame.
>>>>
>>>> Your understanding is correct that: for enabling (generation) representation
>>>> of of .cfi_val_offset {SP|FP|RA}, <offset> in future,  we can use the
>>>> indicated unused bit.
>>>>
>>>> The thinking was what we could _set_ that unused bit to 1 when wanting to
>>>> indicate the semantics of .cfi_val_offset.
>>>>
>>>> That is,
>>>>
>>>>      reg_data = SFRAME_V3_FLEX_FDE_REG_ENCODE (0,1,0,0);
>>>>      offset_data = <offset>
>>>>
>>>> would indicate the semantics of .cfi_val_offset in future.
>>>>
>>>> However, I now realise that for the above then, we will have to have
>>>> (in future):
>>>>
>>>> #define SFRAME_V3_FLEX_FDE_REG_ENCODE(reg, not_invalid_p, deref_p, reg_p)  \
>>>>     ((((reg) << 0x3) | (((not_invalid_p) & 0x1) << 0x2) | (((deref_p) & 0x1) << 0x1) | ((reg_p) & 0x1)))
>>>>
>>>> Perhaps its my general lack of skills in naming things appropriately,
>>>> but I cannot think of an alternative to "not_invalid_p".  That choice
>>>> of name will be generally confusing.
>>>>
>>>> [The PADDING or invalid reg_data will need to be always be defined as zero.]
>>>>
>>>> Perhaps its better to define that unused bit now to adopt the semantics
>>>> of valid_p.  IOW, we start to generate reg_data as:
>>>>
>>>>      reg_data = SFRAME_V3_FLEX_FDE_REG_ENCODE (reg,1,deref_p,reg_p);
>>>>      offset_data = <offset>
>>>>
>>>> Thoughts ?
>>>
>>> I would then use the LSB for valid_p, but that is only my personal
>>> preference:
>>>
>>> ((reg) << 3) | (deref_p << 3) | (reg_p << 2) | (valid_p)
>>>
>>> It would leave no spare bit for any future use.  Currently I can't see why
>>> .cfi_val_offset {SP|FP|RA} would be important.
>>>
> 
> Couldn't .cfi_val_offset be represented as:
> 
> reg_p=0, deref_p=0, reg!=0 (e.g. reg=1)?  The value of reg would not be
> used except for differentiating the register info word from a padding
> data word of zero.
> 

If reg_p == 0, in theory, the bits in the reg field are currently unused 
(we emit a 0 for them if reg_p==0).  So in principle, what you suggest 
is also possible..

>>
>> My judgement is the same that supporting .cfi_val_offset {SP|FP|RA} is not crucial.
>>
>> (I see now that your intention was to get further inputs from folks.  I am fine to keep the bit unused then.  The worst in future, in this case, will be to deal with a awkwardly named field it seems.  We can wait for others to chime in..)
>>
>> Until then, I will keep the status quo (unused bit in 3 position) and post V3 soon.
>>
>>>>> An offset value of zero (on architectures such as s390x that do not use
>>>>> zero as default), would need explicit indication in reg_data to be
>>>>> differentiated from two padding offsets of zero.
> Regards,
> Jens