public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Greg Savin <greg.savin@sifive.com>
To: John Baldwin <jhb@freebsd.org>
Cc: gdb-patches@sourceware.org, binutils@sourceware.org,
	palmer@dabbelt.com,  greentime.hu@sifive.com,
	Andrew Burgess <andrew.burgess@embecosm.com>
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:56:25 -0700	[thread overview]
Message-ID: <CADdv1FpN8d15vDoY_Qs5P5SCa5MeZh9e9Hr6O7da_bjsbim7Uw@mail.gmail.com> (raw)
In-Reply-To: <40cf6dfd-7948-095f-249a-9bac83ff923c@FreeBSD.org>

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

  reply	other threads:[~2023-08-10 18:56 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
2023-08-10 18:56   ` Greg Savin [this message]
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:
  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=CADdv1FpN8d15vDoY_Qs5P5SCa5MeZh9e9Hr6O7da_bjsbim7Uw@mail.gmail.com \
    --to=greg.savin@sifive.com \
    --cc=andrew.burgess@embecosm.com \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    --cc=greentime.hu@sifive.com \
    --cc=jhb@freebsd.org \
    --cc=palmer@dabbelt.com \
    /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 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).