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

[Andrew Burgess <andrew.burgess@embecosm.com>]

* 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.

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?

Thanks,
Andrew

>  
> > It is possible for a user to extract the target description from GDB and pass
> > this along with the core file so that when the core file is used the target
> > description can be fed back into GDB, however this is not a great user
> > experience.
> > 
> > It would be nicer, I think, if GDB could write the target description directly
> > into the core file, and then make use of this description when loading a core
> > file.
> > 
> > This commit performs the binutils/bfd side of this task, adding the boiler
> > plate functions to access the target description from within a core file note,
> > and reserving a new number for a note containing the target description.
> > 
> > Later commits will extend GDB to make use of this.
> 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
>