From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Binutils <binutils@sourceware.org>, gdb-patches@sourceware.org
Subject: Re: [PATCH 2/8] bfd/binutils: support for gdb target descriptions in the core file
Date: Mon, 11 Jan 2021 10:19:48 +0000 [thread overview]
Message-ID: <20210111101948.GA1151657@embecosm.com> (raw)
In-Reply-To: <20201214115512.GI2945@embecosm.com>
* Andrew Burgess <andrew.burgess@embecosm.com> [2020-12-14 11:55:12 +0000]:
> * Luis Machado <luis.machado@linaro.org> [2020-12-03 09:16:33 -0300]:
>
> > 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.
>
> What if I set aside the values 0xff000000 to 0xffffffff for non-os
> specific notes, the new comment and code might look like this:
>
> /* The range 0xff000000 to 0xffffffff is set aside for notes that
> might be applicable for any OS. This range of values will
> hopefully not conflict with OS specific, but architecture
> agnostic notes, which tend to have low values, or architecture
> specific notes that tend to have values in the range 0x100+. */
>
> #define NT_GDB_TDESC 0xff000000
>
> Thoughts?
Ping!
Any thoughts on the above suggestion (using constant 0xff000000)
compared to the original suggestion (using constant 0x54444553)?
Thanks,
Andrew
>
> Thanks,
> Andrew
next prev parent reply other threads:[~2021-01-11 10:19 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
2020-12-02 22:58 ` Jim Wilson
2020-12-03 12:16 ` Luis Machado
[not found] ` <20201214115512.GI2945@embecosm.com>
2021-01-11 10:19 ` Andrew Burgess [this message]
2021-01-11 13:03 ` Luis Machado
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
2020-12-07 15:17 ` Andrew Burgess
2020-12-07 15:58 ` Luis Machado
2020-12-07 16:58 ` Andrew Burgess
2020-12-07 17:24 ` Luis Machado
2020-12-07 18:11 ` Andrew Burgess
2020-12-07 19:00 ` Luis Machado
2020-12-07 19:23 ` Andrew Burgess
2020-12-07 19:39 ` Luis Machado
2020-12-07 19:51 ` Paul Mathieu
2020-12-13 10:13 ` Fredrik Hederstierna
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=20210111101948.GA1151657@embecosm.com \
--to=andrew.burgess@embecosm.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).