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'

Greg Savin via Gdb-patches
2023-08-10T18:58:00Z

Initially I tried reusing 0x900 for NT_RISCV_VECTOR, and leaving
NT_RISCV_CSR in place with its original 0x900 value, and this was resulting
in compile errors of "duplicate case values within a switch statement." So
I figured having duplicate NT_* values was a "no no" at least in the
standards of the GDB project. I'm guessing that particular compile error
can be treated as a warning, but that GDB intentionally chooses compile
flags to treat the duplicate case values as a hard error (?)

--Greg

On Thu, Aug 10, 2023 at 11:39 AM John Baldwin <jhb@freebsd.org> wrote:

> 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 <andrew.burgess@embecosm.com>
> 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:
>
>
> http://lists.infradead.org/pipermail/linux-riscv/2020-December/003910.html
>
> 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
> two.
>
> --
> John Baldwin
>
>