[PATCH 5/8] s390: Represent FP without RA saved in SFrame

[Indu Bhagat]

On 5/26/25 9:15 AM, Jens Remus wrote:
> On 05.05.2025 06:56, Indu Bhagat wrote:
>> On 4/2/25 9:12 AM, Jens Remus wrote:
>>> If an architecture uses both SFrame RA and FP tracking SFrame assumes
>>> that the RA offset is the 2nd offset and the FP offset is the 3rd offset
>>> following a SFrame FRE.  An architecture does not necessarily need to
>>> save both on the stack (or in register) at the same time or even at all.
>>> SFrame cannot represent FP without RA saved on stack (or in a register),
>>> since it cannot distinguish whether the 2nd offset is the RA or FP
>>> offset.
>>>
>>> For S390 use an invalid SFrame RA offset from CFA value of zero as
>>> padding to represent the FP being saved when the RA is not saved.  This
>>> aligns with the existing invalid SFrame fixed RA offset from CFA value
>>> of zero.  In a stack tracer this then also naturally falls into place,
>>> as it can skip restoring the RA in the topmost frame, if both the fixed
>>> RA offset (from SFrame header) and the RA offset (from FDE) are zero,
>>> without any need to test architecture-specific flags.
> 
>>> diff --git a/libsframe/sframe-dump.c b/libsframe/sframe-dump.c
> 
>>> @@ -200,6 +200,10 @@ dump_sframe_func_with_fres (sframe_decoder_ctx *sfd_ctx,
>>>          if (sframe_decoder_get_fixed_ra_offset (sfd_ctx)
>>>          != SFRAME_CFA_FIXED_RA_INVALID)
>>>        strcpy (temp, "f");
>>> +      /* If an ABI does track RA offset, e.g. AArch64 and S390, it can be a
>>> +     dummy as padding to represent FP without RA being saved on stack.  */
>>> +      else if (err[2] == 0 && ra_offset == SFRAME_FRE_RA_OFFSET_INVALID)
>>> +    sprintf (temp, "u*");
>>>          else if (err[2] == 0)
>>>        {
>>>          if (is_sframe_abi_arch_s390 (sfd_ctx)
>>
>> I have slight distaste for "u*" to indicate a dummy padding (especially
>> the *), how about just an "X" ? Or something else if you prefer,
>> basically avoiding the '*'.
> 
> I'll be proposing "U" in V2, as the rule for the register is "undefined".
> Actually "u" would also be fine.  For debugging I wanted to see it being
> used.  Maybe it would be better for the end user not to get distracted by
> that level of detail and use "u"?
> 

To me, the u/U distinct usages make sense as you do in V2.  I think such 
demarcation can be useful for debugging.