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

[Luis Machado]

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.