[PATCH 2/8] bfd/binutils: support for gdb target descriptions in the core file

[Andrew Burgess]

* 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