Re: [PATCH v3 13/16] [gdb/generic] corefile/bug: Fixup (gcore) core file target description reading order

[Luis Machado <luis.machado@arm.com>]

Hi Andrew,

On 7/28/23 04:12, Thiago Jung Bauermann wrote:
> 
> Luis Machado via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
>> Due to the nature of the AArch64 SVE/SME extensions in GDB, each thread
>> can potentially have distinct target descriptions/gdbarches.
>>
>> When loading a gcore-generated core file, at the moment GDB gives priority
>> to the target description dumped to NT_GDB_TDESC.  Though technically correct
>> for most target, it doesn't work correctly for AArch64 with SVE or SME
>> support.
>>
>> The correct approach for AArch64/Linux is to rely on the
>> gdbarch_core_read_description hook, so it can figure out the proper target
>> description for a given thread based on the various available register notes.
>>
>> I think this should work for other architectures as well. If not, we may
>> need to adjust things so all architectures get the information that they
>> need for discovering the target description of the core file.
> 
> The code to load the target description from the core file was added in
> commit 95ce627aeb9d "gdb: write target description into core file", by
> Andrew Burgess. My understanding of that commit message is that it was
> added before the gdbarch hook on purpose, and my reading of:
> 
>  “My primary motivation for adding this feature is that, in a future
>   commit, I will be adding support for bare metal core dumps on some
>   targets.  For RISC-V specifically, I want to be able to dump all the
>   available control status registers.  As different targets will present
>   different sets of register in their target description, including
>   registers that are possibly not otherwise known to GDB I wanted a way
>   to capture these registers in the core dump.”
> 
> is that it doesn't work if reading from the target description comes
> last, though I'm not sure about that. I copied him in this email to see
> if he would like to chime in.
> 

It would be great to have your input on this, as the approaches seem to conflict somewhat.

Could you please take a look at this entry (and, if possible, in the other generic pieces too), to make
sure we can come up with something that works for all cases?

Thanks,
Luis