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

[Indu Bhagat]

Hi Jens,

(Closing the open ends on this patch series..)

On 7/31/25 9:06 AM, Jens Remus wrote:
>>>> 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.
> 

To be clear, I am good with it if the implementation is maintainable 
(and easy to follow).

>> 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.
> 

OK.  I took a look again at your V5. Let go with it then.

>> 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).
> 

Yes thats what I meant: single FRE with ra_undefined_p set for the 
address range from the PC where DW_CFA_undefined RA and onwards until 
the end PC of FDE.

I think we both agree that the other fields (cfa base reg id, RA mangled 
bit) are not useful when ra_undefined_p is set, and resetting them to a 
ground state is a good thing to do.  Your patch was already attempting 
to do that for the FRE (representing DW_CFA_undefined RA).

But in light of keeping SFrame flexible like DWARF in regard to 
representing cfi_undefined RA, your approach is more aligned.

Lets go with your V5 and move forward.

> 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.