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 <greg.savin@sifive.com>]

[-- Attachment #1: Type: text/plain, Size: 3956 bytes --]

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