public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Indu Bhagat <indu.bhagat@oracle.com>, Jens Remus <jremus@linux.ibm.com>
Cc: Andreas Krebbel <krebbel@linux.ibm.com>,
	Richard Earnshaw <rearnsha@arm.com>,
	Marcus Shawcroft <marcus.shawcroft@arm.com>,
	Jan Hubicka <jh@suse.cz>, Andreas Jaeger <aj@suse.de>,
	"H.J. Lu" <hjl.tools@gmail.com>,
	binutils@sourceware.org
Subject: Re: [PATCH v2 3/9] sframe: Enhance comments for SFRAME_CFA_*_REG macros
Date: Mon, 26 Feb 2024 14:51:55 +0100	[thread overview]
Message-ID: <c8503f90-4dde-45cb-8afe-f152ab96a789@suse.com> (raw)
In-Reply-To: <e4a18ce6-57c0-40a2-bcdd-9170415ae324@oracle.com>

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

  reply	other threads:[~2024-02-26 13:51 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 17:07 [RFC PATCH 0/9] s390: Initial support to generate SFrame info from CFI directives in assembler Jens Remus
2024-02-23 17:07 ` [PATCH v2 1/9] x86: Remove unused SFrame CFI RA register variable Jens Remus
2024-02-24  7:38   ` Indu Bhagat
2024-02-26 13:01     ` Jan Beulich
2024-02-26 14:51       ` Jens Remus
2024-02-27  9:08       ` Indu Bhagat
2024-02-27  9:11         ` Jan Beulich
2024-02-26 15:04     ` Jens Remus
2024-02-23 17:07 ` [PATCH v2 2/9] aarch64: Align SFrame terminology in comments to specs and x86 Jens Remus
2024-02-24  7:44   ` Indu Bhagat
2024-02-23 17:07 ` [PATCH v2 3/9] sframe: Enhance comments for SFRAME_CFA_*_REG macros Jens Remus
2024-02-24  7:46   ` Indu Bhagat
2024-02-26 13:51     ` Jan Beulich [this message]
2024-02-27  8:53       ` Indu Bhagat
2024-02-27  8:57         ` Jan Beulich
2024-02-27  9:01           ` Indu Bhagat
2024-02-23 17:07 ` [PATCH v2 4/9] readelf/objdump: Dump SFrame CFA fixed FP and RA offsets Jens Remus
2024-02-24  7:48   ` Indu Bhagat
2024-02-23 17:07 ` [PATCH v2 5/9] gas: Print DWARF call frame insn name in SFrame warning message Jens Remus
2024-02-24  7:56   ` Indu Bhagat
2024-02-26 15:37     ` Jens Remus
2024-02-23 17:07 ` [PATCH v2 6/9] gas: Skip SFrame FDE if CFI specifies non-FP/SP base register Jens Remus
2024-02-24  7:57   ` Indu Bhagat
2024-02-23 17:07 ` [PATCH v2 7/9] gas: Warn if SFrame FDE is skipped due to non-default return column Jens Remus
2024-02-24  8:43   ` Indu Bhagat
2024-02-26 16:19     ` Jens Remus
2024-02-23 17:07 ` [PATCH v2 8/9] gas: User readable warnings if SFrame FDE is not generated Jens Remus
2024-02-29  7:39   ` Indu Bhagat
2024-04-09 14:14     ` Jens Remus
2024-02-23 17:08 ` [RFC PATCH 9/9] s390: Initial support to generate .sframe from CFI directives in assembler Jens Remus
2024-02-29  7:01   ` Indu Bhagat
2024-04-09 15:07     ` Jens Remus
2024-02-23 17:27 ` [RFC PATCH 0/9] s390: Initial support to generate SFrame info " Jens Remus
2024-02-23 21:16 ` Indu Bhagat
2024-04-05 18:26   ` Indu Bhagat
2024-04-09 14:19     ` Jens Remus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c8503f90-4dde-45cb-8afe-f152ab96a789@suse.com \
    --to=jbeulich@suse.com \
    --cc=aj@suse.de \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=indu.bhagat@oracle.com \
    --cc=jh@suse.cz \
    --cc=jremus@linux.ibm.com \
    --cc=krebbel@linux.ibm.com \
    --cc=marcus.shawcroft@arm.com \
    --cc=rearnsha@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).