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

[Jens Remus]

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.

> 
> 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
-- 
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/