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

[Simon Marchi <simon.marchi@polymtl.ca>]

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.

Simon