Re: [PATCH v7 15/18] [gdb/generic] corefile/bug: Add hook to control the use of target description notes from corefiles

[Andrew Burgess <aburgess@redhat.com>]

Simon Marchi <simon.marchi@polymtl.ca> writes:

> On 9/21/23 06:44, Luis Machado via Gdb-patches wrote:
>>>>> For point (2) I agree with the premise that we need a mechanism to stop
>>>>> AArch64 loading the incorrect single NT_GDB_TDESC.  This is a slight
>>>>> change in stance from what I originally wrote, but our IRC conversation
>>>>> showed me I was wrong originally.  I don't have time this evening to
>>>>> look at this, but will follow up again tomorrow with more thoughts.
>>>
>>> I wonder, instead of adding the new hook, maybe we should just reorder
>>> the checks in core_target::read_description -- ask the gdbarch to grok a
>>> tdesc from the .regs (etc) sections, and if that fails, check for an
>>> encoded tdesc.
>>>
>> 
>> That's exactly what I did a few versions earlier. But Simon pointed out it would
>> effectively be a conflicting situation given our choice of defaulting to reading the
>> target description from the NT_GDB_TDESC. So I went with the hook, which, to be honest,
>> seems cleaner.
>
> Hi,
>
> I did not have the complete historical picture when I suggested this,
> Andrew later explained that this was added for some RISC-V target for
> which a tdesc could not be reconstructed from just the dumped register
> state.  I thought that the NT_GDB_TDESC note was a better source of
> truth than just the register state.  My understanding now is that for
> most targets (including AArch64 with SME and friends), reconstructing
> the tdesc from the register state works equally well as reading an
> NT_GDB_TDESC note (that holds the right tdesc).  So, we can say that
> having the NT_GDB_TDESC note there is useless in these cases.
>
> So now, my question is: when we generate a core, should we only generate
> an NT_GDB_TDESC note for those targets for which we know a tdesc note
> will be necessary?  That would involve a gdbarch hook where the arch can
> say "yes please generate a tdesc note in this core", which would default
> to false.

I would not oppose such a change, but the problem here really was that
GDB was just writing out the wrong thing -- the generic, incorrect,
global tdesc, rather than the correct thread specific tdesc.

But you are correct, for hosted environments (Linux, FreeBSD), where the
OS can create a core file without a NT_GDB_TDESC, we really do need to
be able to figure out the architecture just from the core file contents,
so dropping the NT_GDB_TDESC for these cases really shouldn't be a
problem.

Thanks,
Andrew