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 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 > 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 > >