[PATCHv2 2/9] bfd/binutils: support for gdb target descriptions in the core file

[Strasuns, Mihails]

> -----Original Message-----
> From: Andrew Burgess <andrew.burgess@embecosm.com>
> Sent: Friday, January 22, 2021 8:30 PM
> To: Strasuns, Mihails <mihails.strasuns@intel.com>
> Cc: gdb-patches@sourceware.org; binutils@sourceware.org; Fredrik
> Hederstierna <fredrik@hederstierna.com>
> Subject: Re: [PATCHv2 2/9] bfd/binutils: support for gdb target descriptions
> in the core file
> 
> * Strasuns, Mihails <mihails.strasuns@intel.com> [2021-01-22 10:47:23
> +0000]:
> 
> > > -----Original Message-----
> > > From: Gdb-patches <gdb-patches-bounces@sourceware.org> On Behalf
> Of
> > > Andrew Burgess
> > > Sent: Wednesday, January 20, 2021 9:23 PM
> > > To: gdb-patches@sourceware.org; binutils@sourceware.org
> > > Cc: Fredrik Hederstierna <fredrik@hederstierna.com>
> > > Subject: [PATCHv2 2/9] bfd/binutils: support for gdb target
> > > descriptions in the core file
> > >
> > > This commit lays the ground work for allowing GDB to write its
> > > target description into a generated core file.
> > >
> > > The goal of this work is to allow a user to connect to a remote
> > > target, capture a core file from within GDB, then pass the
> > > executable and core file to another user and have the user be able
> > > to examine the state of the machine without needing to connect to a
> running target.
> > >
> > > Different remote targets can have different register sets and this
> > > information is communicated from the target to GDB in the target
> description.
> >
> > Why is it necessary to store a GDB target description for this? Core
> > files already define machine/arch, same as executable ELFs. There
> > still can be some register variation between different platform
> > versions, but it would still need to be denoted somehow in a native
> > core file.
> >
> > My concern is for making a "GDB core file" and a "native core file"
> > even more different than it is currently on Linux. I guess this is
> > aimed at a barebone environments where there is currently no native
> > core dump support at all but even there it is not guaranteed.
> 
> I was following you until "... but even there it is not guaranteed."
> I'm not sure what it is that is not guaranteed.

I have meant that even for a barebone platform that doesn't have any native core dump capabilities it theoretically can be added through firmware - and GDB would want to support that format too.
>From you description below it seems impractical to worry about it right now though.

> Yes, absolutely my interest here is bare metal core dumps, but I don't see
> including the target description in all core files as a big problem.
> 
> I'm not aware that GDB was ever aiming to create core dumps that would be
> identical to kernel produced dumps, just that they should be compatible.
> 
> Including an extra note should be transparent to any well behaved tool (I'd
> hope), or at worst maybe a warning about not understanding the note
> 
> The problem I'm trying to solve is that the RISC-V targets I'm working with
> have a pretty random collection of control status registers (CSRs), included
> off-spec registers.  I'd like to capture these in the core dump, so the
> approach I have right now is just dump all of them in target description order.
>
> Anyway, back to your concerns...
> 
> ...would making target description inclusion optional/switchable be enough
> to alleviate your concerns?  Would you rather it was default off, or would you
> be happy with switchable default on?

I don't have a strong preference here, it is probably fine as it is. GDB test suite covers both native core and a generated one as separate test cases, correct? 

Context: I am currently looking into core dump support for Intel GPUs and using generate-core as a convenient way to quickly iterate through the different format prototypes.
However it is not affected by your patch, I was more curious/concerned about a general direction here.

> Thanks,
> Andrew
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928