[PATCH 3/4] gas: sframe: handle .cfi_undefined

[Indu Bhagat]

On 5/14/25 11:28 PM, Jan Beulich wrote:
> On 15.05.2025 00:55, Indu Bhagat wrote:
>> On 5/13/25 11:28 PM, Jan Beulich wrote:
>>> On 13.05.2025 22:27, Indu Bhagat wrote:
>>>> On 5/13/25 6:06 AM, Jan Beulich wrote:
>>>>> On 11.05.2025 09:35, Indu Bhagat wrote:
>>>>>> --- a/gas/gen-sframe.c
>>>>>> +++ b/gas/gen-sframe.c
>>>>>> @@ -1507,6 +1507,32 @@ sframe_xlate_do_cfi_escape (const struct sframe_xlate_ctx *xlate_ctx,
>>>>>>       return err;
>>>>>>     }
>>>>>>     
>>>>>> +/* Translate DW_CFA_undefined into SFrame context.
>>>>>> +
>>>>>> +   DW_CFA_undefined op implies that from now on the previous value of register
>>>>>> +   can’t be restored anymore.  In SFrame stack trace, we cannot represent such
>>>>>> +   a semantic.  So, we skip generating an SFrame FDE for this, when a register
>>>>>> +   of interest is used with DW_CFA_undefined.
>>>>>> +
>>>>>> +   Return SFRAME_XLATE_OK if success.  */
>>>>>> +
>>>>>> +static int
>>>>>> +sframe_xlate_do_cfi_undefined (const struct sframe_xlate_ctx *xlate_ctx ATTRIBUTE_UNUSED,
>>>>>> +			       const struct cfi_insn_data *cfi_insn)
>>>>>> +{
>>>>>> +  if (cfi_insn->u.ri.reg == SFRAME_CFA_FP_REG
>>>>>> +      || cfi_insn->u.ri.reg == SFRAME_CFA_RA_REG
>>>>>> +      || cfi_insn->u.ri.reg == SFRAME_CFA_SP_REG)
>>>>>> +    {
>>>>>> +      as_warn (_("skipping SFrame FDE; %s reg %u in .cfi_undefined"),
>>>>> As the comment says, what you skip is generating an FDE; you don't skip any
>>>>> FDE itself afaict. I think this needs reflecting in the diagnostic, for it
>>>>> to not be confusing.
>>>> Can you elaborate - it is not clear what you mean. Yes, what we skip is
>>>> generating an SFrame FDE.  The diagnostic "skipping SFrame FDE" is meant
>>>> to indicate that there will be no SFrame FDE for that function/block.
>>> The message as it is tells me that there is an FDE (somewhere) which is
>>> being skipped. It does not tell me that my expectation of an FDE being
>>> generated is not met. "not emitting ..." or "no ... emitted: ..." or
>>> some such would be what I think makes things more clear.
>>
>> I have slight preference to not change the warning messages now.  I am
>> afraid users may have gotten used to grepping for "skipping SFrame FDE"
>> over time.
> 
> Well, SFrame is still pretty new and perhaps even still kind of experimental.
> When, if not now, would you suggest to make such an adjustment? It's bad
> enough that the ambiguity made it in originally. I, for one, will certainly
> not approve new code with unclear diagnostics.
> 

OK then.

I have added a patch to the series to reword all the existing warnings 
to : "no SFrame FDE emitted; ...".

Thanks for reviewing