From: Jim Wilson <jimw@sifive.com>
To: Luis Machado <luis.machado@linaro.org>
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: Wed, 2 Dec 2020 14:58:35 -0800 [thread overview]
Message-ID: <CAFyWVaZszeSTpchdyNEKNsnzeCN6gr1JhnmjRnxhkQB3+gM_1Q@mail.gmail.com> (raw)
In-Reply-To: <98c2b9bb-10bc-5141-19cf-0705e2e97ec0@linaro.org>
On Wed, Dec 2, 2020 at 10:21 AM Luis Machado via Gdb-patches <
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.
Jim
next prev parent reply other threads:[~2020-12-02 22:58 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 [this message]
2020-12-03 12:16 ` Luis Machado via Gdb-patches
[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=CAFyWVaZszeSTpchdyNEKNsnzeCN6gr1JhnmjRnxhkQB3+gM_1Q@mail.gmail.com \
--to=jimw@sifive.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--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