[PATCH v2 3/9] sframe: Enhance comments for SFRAME_CFA_*_REG macros
Indu Bhagat
indu.bhagat@oracle.com
Tue Feb 27 09:01:55 GMT 2024
On 2/27/24 00:57, Jan Beulich wrote:
> On 27.02.2024 09:53, Indu Bhagat wrote:
>> On 2/26/24 05:51, Jan Beulich wrote:
>>> On 24.02.2024 08:46, Indu Bhagat wrote:
>>>> On 2/23/24 09:07, Jens Remus wrote:
>>>>> --- a/gas/config/tc-aarch64.h
>>>>> +++ b/gas/config/tc-aarch64.h
>>>>> @@ -267,15 +267,15 @@ extern void aarch64_after_parse_args (void);
>>>>> extern bool aarch64_support_sframe_p (void);
>>>>> #define support_sframe_p aarch64_support_sframe_p
>>>>>
>>>>> -/* The stack-pointer register number for SFrame stack trace info. */
>>>>> +/* The stack-pointer register number for CFA tracking. */
>>>>
>>>> What do you think about including "SFrame" in all the touched comments
>>>> in this patch. So something like:
>>>>
>>>> /* The stack-pointer register number for SFrame CFA tracking. */
>>>>
>>>> above ...
>>>>
>>>>> extern unsigned int aarch64_sframe_cfa_sp_reg;
>>>>> #define SFRAME_CFA_SP_REG aarch64_sframe_cfa_sp_reg
>>>>>
>>>>> -/* The frame-pointer register number for SFrame stack trace info. */
>>>>> +/* The frame-pointer register number for CFA and FP tracking. */
>>>>
>>>> ... and here
>>>>
>>>>> extern unsigned int aarch64_sframe_cfa_fp_reg;
>>>>> #define SFRAME_CFA_FP_REG aarch64_sframe_cfa_fp_reg
>>>>>
>>>>> -/* The return address register number for SFrame stack trace info. */
>>>>> +/* The return address register number for RA tracking. */
>>>>
>>>> and here. And others below :)
>>>
>>> Question is: In how far are these variables sframe-specific? On x86 at
>>> least they exactly match the Dwarf2 register numbers, and hence are
>>> in principle pretty generic as to potential future usage. In which
>>> case rather than adding SFrame to the comments, I'd wonder in how far
>>> "sframe" may want purging from their names instead.
>>>
>>
>> So far, the names contained "sframe" solely because that was the only
>> user of these definitions.
>>
>>> In fact on x86 I think these could be #define-s instead of variables,
>>> at least as long as only 64-bit code is supported for anything using
>>> these values.
>>>
>>
>> Makes sense. Now that we have some code in SCFI and elsewhere in x86
>> using these DWARF numbers for SP/FP, we can revisit the names etc once
>> Jan's patch that defines them for x86 goes in.
>
> I'm confused: Which my patch?
>
Sorry, I was thinking about "[PATCH v3] x86: adjust which Dwarf2
register numbers to use"
https://sourceware.org/pipermail/binutils/2024-February/132623.html, and
mistakenly thought your patch defines the REG_FP/REG_SP afresh.
More information about the Binutils
mailing list