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

Luis Machado via Gdb-patches
2021-01-11T13:03:30Z

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