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

[Luis Machado <luis.machado@linaro.org>]

Hi Andrew,

On 1/11/21 7:19 AM, Andrew Burgess wrote:
> * 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)?

Sorry. I missed this reply. The new constant pattern (0xff000000) looks 
OK to me.

> 
> Thanks,
> Andrew
> 
>>
>> Thanks,
>> Andrew