public inbox for
 help / color / mirror / Atom feed
From: John Baldwin <>
To: Greg Savin <>,,,,,
	Andrew Burgess <>
Subject: Re: [PATCH] Re-map value of NT_RISCV_CSR to not collide with the value of NT_RISCV_VECTOR in Linux kernel header file 'include/uapi/linux/elf.h'
Date: Thu, 10 Aug 2023 11:39:25 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 8/9/23 10:53 AM, Greg Savin via Gdb-patches wrote:
> Linux kernel's file 'include/uapi/linux/elf.h' declares the value 0x900
> for NT_RISCV_VECTOR, and does not have a definition for NT_RISCV_CSR, nor
> does it use the value 0x901 for any note type.  This patch is intended
> as a way to resolve the disagreement/collision between Linux and binutils,
> over the meaning of 0x900 in the context of note types.
> ---
>   include/elf/common.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/include/elf/common.h b/include/elf/common.h
> index ffa6b60bd2b..0bbe245519e 100644
> --- a/include/elf/common.h
> +++ b/include/elf/common.h
> @@ -713,7 +713,7 @@
>   					/*   note name must be "LINUX".  */
>   #define NT_LARCH_LBT    0xa04		/* LoongArch Binary Translation registers */
>   					/*   note name must be "CORE".  */
> -#define NT_RISCV_CSR    0x900		/* RISC-V Control and Status Registers */
> +#define NT_RISCV_CSR    0x901		/* RISC-V Control and Status Registers */
>   					/*   note name must be "LINUX".  */
>   #define NT_SIGINFO	0x53494749	/* Fields of siginfo_t.  */
>   #define NT_FILE		0x46494c45	/* Description of mapped files.  */

If there aren't any active uses of NT_RISCV_CSR "in the wild", then it might be
better to just remove it entirely?

It looks like commit e214f8db56f65531b0a5ec296c42339dcaa5af31 adding LoongArch
constants inadvertently changed the comment for this note from "CORE" (a
binutils note) to "LINUX" (a Linux kernel note).

The log message adding NT_RISCV_CSR is clearer (though the comment in common.h
is wrong and should be "GDB" it seems):

commit db6092f3aec43ea4d10efc5ff74274f04cdc0ad6
Author: Andrew Burgess <>
Date:   Fri Nov 27 14:04:16 2020 +0000

     bfd/binutils: add support for RISC-V CSRs in core files
     Adds support for including RISC-V control and status registers into
     core files.
     The value for the define NT_RISCV_CSR is set to 0x900, this
     corresponds to a patch I have proposed for the Linux kernel here:
     As I have not yet heard if the above patch will be accepted into the
     kernel or not I have set the note name string to "GDB", and the note
     type to NT_RISCV_CSR.
     This means that if the above patch is rejected from the kernel, and
     the note type number 0x900 is assigned to some other note type, we
     will still be able to distinguish between the GDB produced
     NT_RISCV_CSR, and the kernel produced notes, where the name would be
     set to "CORE".

Seems like the kernel patch died on the vine (no responses to the patch).
GDB does support writing this out still though via the ".reg.riscv-csr"
pseudo section, so changing this would break debugging bare metal core
dumps.  You can however, just re-use 0x900 for NT_RISCV_VECTOR without
this patch.  The different note name is sufficient to differentiate the

John Baldwin

  reply	other threads:[~2023-08-10 18:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-09 17:53 Greg Savin
2023-08-10 18:39 ` John Baldwin [this message]
2023-08-10 18:56   ` Greg Savin
2023-08-10 20:00     ` John Baldwin
2023-08-10 22:11       ` Greg Savin
2023-08-10 22:11         ` [PATCH v2 1/2] Reset note name of NT_RISCV_CSR to "GDB" to be consistent with the intent described in commit db6092f3aec43ea4d10efc5ff74274f04cdc0ad6 Greg Savin
2023-08-11 12:23           ` Andrew Burgess
2023-08-10 22:11         ` [PATCH v2 2/2] Propagate NT_RISCV_VECTOR from Linux kernel headers to binutils. The value is identical to pre-existing NT_RISCV_CSR but the note names different (NT_RISCV_CSR is "GDB" and NT_RISCV_VECTOR is "CORE") Greg Savin
2023-08-11 12:51           ` Andrew Burgess
2023-08-11 16:43             ` Palmer Dabbelt
2023-08-12  0:47               ` John Baldwin
2023-08-12  0:50                 ` Palmer Dabbelt

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:

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

  git send-email \ \ \ \ \ \ \ \ \

* 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).