All of lore.kernel.org
 help / color / mirror / Atom feed
From: Enze Li <lienze@kylinos.cn>
To: WANG Xuerui <kernel@xen0n.name>
Cc: Huacai Chen <chenhuacai@kernel.org>,
	 loongarch@lists.linux.dev,  WANG Xuerui <git@xen0n.name>
Subject: Re: [PATCH v7 03/12] LoongArch: Print GPRs with ABI names when showing registers
Date: Thu, 27 Apr 2023 10:07:57 +0800	[thread overview]
Message-ID: <87leie6ps2.fsf@kylinos.cn> (raw)
In-Reply-To: <293fb6d9-db3a-1435-5f1a-55103677d42c@xen0n.name> (WANG Xuerui's message of "Tue, 25 Apr 2023 21:39:13 +0800")

On Tue, Apr 25 2023 at 09:39:13 PM +0800, WANG Xuerui wrote:

> On 2023/4/25 21:06, Enze Li wrote:
>> Hi Xuerui,
>> Thanks for doing this.  Overall, I like this idea, but I think I
>> found
>> an easily fixable problem in this patch, please see below.
>> On Tue, 2023-04-25 at 16:10 +0800, WANG Xuerui wrote:
>>> From: WANG Xuerui <git@xen0n.name>
>>>
>>> Show PC (CSR.ERA) in place of $zero, and also show the syscall
>>> restart
>>> flag (conveniently stuffed in regs[0]) if non-zero.
>>>
>>> Signed-off-by: WANG Xuerui <git@xen0n.name>
>>> ---
>>>   arch/loongarch/kernel/traps.c | 36 ++++++++++++++++++++++-----------
>>> --
>>>   1 file changed, 23 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/arch/loongarch/kernel/traps.c
>>> b/arch/loongarch/kernel/traps.c
>>> index 529165eb6e6b..cdb17d6afc77 100644
>>> --- a/arch/loongarch/kernel/traps.c
>>> +++ b/arch/loongarch/kernel/traps.c
>>> @@ -158,22 +158,32 @@ static void __show_regs(const struct pt_regs
>>> *regs)
>>>          const int field = 2 * sizeof(unsigned long);
>>>          unsigned int excsubcode;
>>>          unsigned int exccode;
>>> -       int i;
>>>            show_regs_print_info(KERN_DEFAULT);
>>>   -       /*
>>> -        * Saved main processor registers
>>> -        */
>>> -       for (i = 0; i < 32; ) {
>>> -               if ((i % 4) == 0)
>>> -                       printk("$%2d   :", i);
>>> -               pr_cont(" %0*lx", field, regs->regs[i]);
>>> -
>>> -               i++;
>>> -               if ((i % 4) == 0)
>>> -                       pr_cont("\n");
>>> -       }
>>> +       /* Print GPRs except $zero (substituting with PC/ERA) */
>>> +#define GPR_FIELD(x) field, regs->regs[x]
>> The checkpatch.pl throws up the following error,
>> -------------------------------------------------------------------
>> ERROR: Macros with complex values should be enclosed in parentheses
>> #40: FILE: arch/loongarch/kernel/traps.c:165:
>> +#define GPR_FIELD(x) field, regs->regs[x]
>> -------------------------------------------------------------------
>> and I think adding a pair of parentheses is a good way, like this,
>> =======================================================================
>> --- a/arch/loongarch/kernel/traps.c
>> +++ b/arch/loongarch/kernel/traps.c
>> @@ -162,7 +162,7 @@ static void __show_regs(const struct pt_regs *regs)
>>          show_regs_print_info(KERN_DEFAULT);
>>            /* Print GPRs except $zero (substituting with PC/ERA) */
>> -#define GPR_FIELD(x) field, regs->regs[x]
>> +#define GPR_FIELD(x) (field, regs->regs[x])
>
> Have you checked whether the code even compiles after making this change?
>
> The macro use here is deliberate because otherwise for every register
> printed we would have to repeat the "field" argument once, leading to
> very long lines or more vertical space occupied. (The kernel vsprintf
> implementation doesn't support overriding argument positions like with
> "%0*1$lx", unlike modern C.)

Yeah, you're right.  Things are not always what they appear to be.

I tried several other ways, but they all failed.  I think your method
should be the most suitable.

>
>>          pr_cont("pc %0*lx ra %0*lx tp %0*lx sp %0*lx\n",
>>                  field, regs->csr_era, GPR_FIELD(1), GPR_FIELD(2),
>> GPR_FIELD(3));
>>          pr_cont("a0 %0*lx a1 %0*lx a2 %0*lx a3 %0*lx\n",
>> =======================================================================
>> In addition, the checkpatch.pl also throws up some warnings.  Should
>> these use pr_info() instead?
>
> Hmm perhaps. I originally thought of the whole show_regs output as one
> entry. Now I see how that's not the case and I'll tweak a bit. Thanks
> for pointing out.
>
>> --------------------------------------------------------
>> WARNING: Avoid logging continuation uses where feasible
>> #41: FILE: arch/loongarch/kernel/traps.c:166:
>> +	pr_cont("pc %0*lx ra %0*lx tp %0*lx sp %0*lx\n",
>> WARNING: Avoid logging continuation uses where feasible
>> #43: FILE: arch/loongarch/kernel/traps.c:168:
>> +	pr_cont("a0 %0*lx a1 %0*lx a2 %0*lx a3 %0*lx\n",
>> WARNING: Avoid logging continuation uses where feasible
>> #45: FILE: arch/loongarch/kernel/traps.c:170:
>> +	pr_cont("a4 %0*lx a5 %0*lx a6 %0*lx a7 %0*lx\n",
>> --------------------------------------------------------
>> Best Regards,
>> Enze
>> 
>>> +       pr_cont("pc %0*lx ra %0*lx tp %0*lx sp %0*lx\n",
>>> +               field, regs->csr_era, GPR_FIELD(1), GPR_FIELD(2),
>>> GPR_FIELD(3));
>>> +       pr_cont("a0 %0*lx a1 %0*lx a2 %0*lx a3 %0*lx\n",
>>> +               GPR_FIELD(4), GPR_FIELD(5), GPR_FIELD(6),
>>> GPR_FIELD(7));
>>> +       pr_cont("a4 %0*lx a5 %0*lx a6 %0*lx a7 %0*lx\n",
>>> +               GPR_FIELD(8), GPR_FIELD(9), GPR_FIELD(10),
>>> GPR_FIELD(11));
>>> +       pr_cont("t0 %0*lx t1 %0*lx t2 %0*lx t3 %0*lx\n",
>>> +               GPR_FIELD(12), GPR_FIELD(13), GPR_FIELD(14),
>>> GPR_FIELD(15));
>>> +       pr_cont("t4 %0*lx t5 %0*lx t6 %0*lx t7 %0*lx\n",
>>> +               GPR_FIELD(16), GPR_FIELD(17), GPR_FIELD(18),
>>> GPR_FIELD(19));
>>> +       pr_cont("t8 %0*lx u0 %0*lx s9 %0*lx s0 %0*lx\n",
>>> +               GPR_FIELD(20), GPR_FIELD(21), GPR_FIELD(22),
>>> GPR_FIELD(23));
>>> +       pr_cont("s1 %0*lx s2 %0*lx s3 %0*lx s4 %0*lx\n",
>>> +               GPR_FIELD(24), GPR_FIELD(25), GPR_FIELD(26),
>>> GPR_FIELD(27));
>>> +       pr_cont("s5 %0*lx s6 %0*lx s7 %0*lx s8 %0*lx\n",
>>> +               GPR_FIELD(28), GPR_FIELD(29), GPR_FIELD(30),
>>> GPR_FIELD(31));
>>> +
>>> +       /* The slot for $zero is reused as the syscall restart flag
>>> */
>>> +       if (regs->regs[0])
>>> +               pr_cont("syscall restart flag: %0*lx\n",
>>> GPR_FIELD(0));

>>> +#undef GPR_FIELD

BTW, I like this habit.  It makes it clearer to see the scope of what
the macro applies to, thank you.

Cheers!
Enze

>>>            /*
>>>           * Saved csr registers
>> 

  reply	other threads:[~2023-04-27  2:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-25  8:10 [PATCH v7 00/12] LoongArch: Better backtraces WANG Xuerui
2023-04-25  8:10 ` [PATCH v7 01/12] LoongArch: Clean up the architectural interrupt definitions WANG Xuerui
2023-04-25  8:10 ` [PATCH v7 02/12] LoongArch: Add exception subcode definitions for the watchpoint exception WANG Xuerui
2023-04-25  8:10 ` [PATCH v7 03/12] LoongArch: Print GPRs with ABI names when showing registers WANG Xuerui
2023-04-25 13:06   ` Enze Li
2023-04-25 13:39     ` WANG Xuerui
2023-04-27  2:07       ` Enze Li [this message]
2023-04-25  8:10 ` [PATCH v7 04/12] LoongArch: Print symbol info for CSR.ERA and $ra only for kernel-mode contexts WANG Xuerui
2023-04-25  8:10 ` [PATCH v7 05/12] LoongArch: Fix format of CSR lines during show_regs WANG Xuerui
2023-04-25  8:10 ` [PATCH v7 06/12] LoongArch: Humanize the CRMD line when showing registers WANG Xuerui
2023-04-25 13:23   ` Enze Li
2023-04-25  8:10 ` [PATCH v7 07/12] LoongArch: Humanize the PRMD " WANG Xuerui
2023-04-25  8:10 ` [PATCH v7 08/12] LoongArch: Humanize the EUEN " WANG Xuerui
2023-04-25  8:10 ` [PATCH v7 09/12] LoongArch: Humanize the ECFG " WANG Xuerui
2023-04-25  8:10 ` [PATCH v7 10/12] LoongArch: Humanize the ESTAT " WANG Xuerui
2023-04-25  8:10 ` [PATCH v7 11/12] LoongArch: Use ISA manual names for BADV and CPUCFG.PRID lines in show_regs WANG Xuerui
2023-04-25  8:10 ` [PATCH v7 12/12] LoongArch: Also include current CPU's full name in show_regs output WANG Xuerui

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=87leie6ps2.fsf@kylinos.cn \
    --to=lienze@kylinos.cn \
    --cc=chenhuacai@kernel.org \
    --cc=git@xen0n.name \
    --cc=kernel@xen0n.name \
    --cc=loongarch@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.