[PATCH v4 3/4] gas: sframe: Represent .cfi_undefined RA as FRE without offsets

[Jens Remus]

On 7/30/2025 7:50 PM, Indu Bhagat via Binutils wrote:
> On 7/30/25 5:38 AM, Jens Remus wrote:
>> On 7/30/2025 10:30 AM, Indu Bhagat wrote:
>>> On 7/29/25 4:19 AM, Jens Remus wrote:
>>
>>>> My intend was to set as much of the FRE info word zero as possible,
>>>> to make it easier for humans to parse SFrame data for debugging
>>>> purposes.  I did not touch mangled_ra_p, as I was unsure whether
>>>> that can also be unconditionally set to zero.  But I guess that
>>>> would be fine?
>>>>
>>>> I used zero, to denote that this is about setting the field to zero
>>>> instead of a specific value with an assigned meaning, like
>>>> SFRAME_BASE_REG_SP.

...

>>> How about we reset the state of cur_fre when handling the case in
>>> sframe_xlate_do_cfi_undefined () itself. Then this handling in
>>> output_sframe_row_entry will not be necessary.
>>
>> Do you happen to know how this is handled in objdump -WF for DWARF?
>> I guess it only affects the RA register (return column register).
>> So we should not alter any other register rules, such as CFA base
>> register, CFA offset, and FP offset.  In theory the next FRE could
>> define a valid rule for the RA register, no?
>>
> 
> IIUC, for DWARF, this only affects the RA register rule.
> 
> RE: can next FRE define a new valid rule
> 
> In theory, the next insns could define a valid rule, yes.  But for
> what register? For RA, it doesnt make sense to me.  For other
> registers (CFA, FP), may be ... but again, why and whats the usecase...
> So, the question is whether supporting the additional complexity
> necessary in SFrame ? Is there a usecase to having a function which
> is the outermost frame in a subset of IPs, and not outermost in the
> other subset ?

I honestly don't know.  But DWARF can represent that.  And it would
be possible to do the same in SFrame using my current approach.

> My opinion is to not complicate the implementation at this time.  I
> think for DWARF we know it makes sense, because it is quite flexible
> and allows DW_CFA_undefined for any register.  But for SFrame, we
> are interested in representing a specific case "DW_CFA_undefined RA"
> which has a very specific meaning especially if the context is
> limited to stack tracing (and not register restoration or stack
> unwinding).  Hence, we can keep the implementation simple too.

You decide.  My take is that we do not really add any complication
by the current approach.

> What do you think about:
>  - When processing a "DW_CFA_undefined RA", we simply skip processing
>    any further cfi_insn, by returning an error code from
>    sframe_xlate_do_cfi_undefined (), and then the handling it in
>    sframe_do_fde to just emit the FDE.  Something like:
> 
> In sframe_xlate_do_cfi_undefined ():
> 
>   if (cfi_insn->u.r == SFRAME_CFA_RA_REG)
>     {
>       ...
>       return SFRAME_XLATE_ERR_OUTERMOST_FRAME;
>     }
> 
> In sframe_do_fde (), handle the error code to do what is necessary
> (any cleanup, linking FDE etc).
> 
> So IIRC, similar to what you were doing in your initial patches for
> "SFrame FDE with no FREs"
What you suggest is to throw away any FREs, add a single FRE with
ra_undefined_p set and all other fields zeroed?  That would not
require the flag to be maintained elsewhere, but would still require
output_sframe_row_entry to be changed to output a FRE without any
offsets (and preferably a FRE info word of zero).

I will be away from keyboard for a few weeks.  Feel free to continue
where I left off, or I can explore that am back.

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/