From: Luis Machado via Gdb-patches <gdb-patches@sourceware.org>
To: Jim Wilson <jimw@sifive.com>
Cc: gdb-patches@sourceware.org, Binutils <binutils@sourceware.org>
Subject: Re: [PATCH 2/8] bfd/binutils: support for gdb target descriptions in the core file
Date: Thu, 3 Dec 2020 09:16:33 -0300 [thread overview]
Message-ID: <706a8b29-7c5c-a238-a78b-59637b8eb61b@linaro.org> (raw)
In-Reply-To: <CAFyWVaZszeSTpchdyNEKNsnzeCN6gr1JhnmjRnxhkQB3+gM_1Q@mail.gmail.com>
On 12/2/20 7:58 PM, Jim Wilson wrote:
> On Wed, Dec 2, 2020 at 10:21 AM Luis Machado via Gdb-patches
> <gdb-patches@sourceware.org <mailto:gdb-patches@sourceware.org>> wrote:
>
> For the constant, I find the magic number amusing, but I don't think it
> does any good when you're trying to find out why that particular magic
> number was picked, and what the next number should be.
>
> Should we go with the basic increasing ID instead? I think this
> would be
> 7, right after NT_AUXV.
>
>
> 7 is NT_FREEBSD_THRMISC which would prevent use of this on FreeBSD. I
> know this is primarily for bare metal core files, but it might be useful
> for linux and *bsd systems that have different register sets, because of
> different extensions, with vector versus without vector, or because
> different hardware has different sets of implemented CSRs. We don't
> appear to have reserved ranges for NT_* values, though we sort of have a
> scheme for processor specific values, e.g. 0x1XX for ppc, 0x2XX for x86,
> 0x3XX for s390, etc. OS specific values tend to be low values below
> 0x100 but above 6, with only FreeBSD starting at 7 and most others
> starting at 10. So that leaves high values like ascii encodings of the
> NT_* name as safe for new uses. There are 3 of these already, this
> would be a fourth one.
Sure, we should make this generic for all OS' to use.
The processor-specific values are a good example of organized ID
structure. They're all pretty obvious to look at and to identify.
If the OS-specific values are low ID's, then maybe we should start a new
range of high values for the generic NT_* notes. That should make things
more organized in the future, and folks will know what the next ID is.
I don't particularly think having 3 ascii encoded constants is a good
motivation for having more. NT_PRXFPREG is Linux-specific, which is not
good.
Otherwise, if we're sticking to the ascii encodings, we should document
that and group them together in their own section instead of just
grouping them with the Linux ones, which is a bit misleading.
next prev parent reply other threads:[~2020-12-03 12:16 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-02 17:39 [PATCH 0/8] Bare-metal core dumps for RISC-V Andrew Burgess
2020-12-02 17:39 ` [PATCH 1/8] gdb/riscv: use a single regset supply function for riscv fbsd & linux Andrew Burgess
2021-01-18 14:15 ` Andrew Burgess
2020-12-02 17:39 ` [PATCH 2/8] bfd/binutils: support for gdb target descriptions in the core file Andrew Burgess
2020-12-02 18:21 ` Luis Machado via Gdb-patches
2020-12-02 22:58 ` Jim Wilson
2020-12-03 12:16 ` Luis Machado via Gdb-patches [this message]
[not found] ` <20201214115512.GI2945@embecosm.com>
2021-01-11 10:19 ` Andrew Burgess
2021-01-11 13:03 ` Luis Machado via Gdb-patches
2020-12-07 12:48 ` Andrew Burgess
2020-12-02 17:39 ` [PATCH 3/8] gdb: write target description into " Andrew Burgess
2020-12-03 20:36 ` Tom Tromey
2020-12-07 14:38 ` Andrew Burgess
2020-12-02 17:39 ` [PATCH 4/8] bfd/riscv: prepare to handle bare metal core dump creation Andrew Burgess
2020-12-02 23:24 ` Jim Wilson
2020-12-07 14:39 ` Andrew Burgess
2020-12-02 17:39 ` [PATCH 5/8] gdb/riscv: introduce bare metal core dump support Andrew Burgess
2020-12-02 18:12 ` Luis Machado via Gdb-patches
2020-12-07 15:17 ` Andrew Burgess
2020-12-07 15:58 ` Luis Machado via Gdb-patches
2020-12-07 16:58 ` Andrew Burgess
2020-12-07 17:24 ` Luis Machado via Gdb-patches
2020-12-07 18:11 ` Andrew Burgess
2020-12-07 19:00 ` Luis Machado via Gdb-patches
2020-12-07 19:23 ` Andrew Burgess
2020-12-07 19:39 ` Luis Machado via Gdb-patches
2020-12-07 19:51 ` Paul Mathieu via Gdb-patches
2020-12-13 10:13 ` Fredrik Hederstierna via Gdb-patches
2020-12-02 17:39 ` [PATCH 6/8] bfd/binutils: add support for RISC-V CSRs in core files Andrew Burgess
2020-12-02 23:50 ` Jim Wilson
2020-12-07 15:19 ` Andrew Burgess
2020-12-14 13:37 ` Andrew Burgess
2020-12-02 17:39 ` [PATCH 7/8] gdb/riscv: make riscv target description names global Andrew Burgess
2020-12-02 17:39 ` [PATCH 8/8] gdb/riscv: write CSRs into baremetal core dumps Andrew Burgess
2020-12-02 23:59 ` [PATCH 0/8] Bare-metal core dumps for RISC-V Jim Wilson
2020-12-07 12:10 ` Andrew Burgess
2020-12-07 19:57 ` Jim Wilson
2020-12-03 20:40 ` Tom Tromey
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=706a8b29-7c5c-a238-a78b-59637b8eb61b@linaro.org \
--to=gdb-patches@sourceware.org \
--cc=binutils@sourceware.org \
--cc=jimw@sifive.com \
--cc=luis.machado@linaro.org \
/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