[PATCH v2 3/9] sframe: Enhance comments for SFRAME_CFA_*_REG macros

[Jan Beulich]

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.

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.

Jan