[PATCHv2 2/9] bfd/binutils: support for gdb target descriptions in the core file
Andrew Burgess
andrew.burgess@embecosm.com
Mon Jan 25 11:20:42 GMT 2021
* Strasuns, Mihails <mihails.strasuns@intel.com> [2021-01-25 10:11:42 +0000]:
> > -----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.
Sure, but for some arbitrary format that would require significant
change in both BFD and GDB probably.
Certainly in the past when I've worked with various non-standard dump
formats its been easier to write a tool that converts the format to
ELF + NOTES and then load that in the normal way.
But I don't see the connection between this and adding target
descriptions to GDB generated dumps.
> From you description below it seems impractical to worry about it
> right now though.
I'm more worried that I don't understand what I should be worried
about :-/
>
> > 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?
Yes I believe that there are at least some tests that rely on the OS
to generate a core file.
> 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.
For me personally, I would be happy with GDB adding any additional
information that it knows about the target into a generated core
file.
I'd be willing to accept that this might mean that a GDB generated
core file is more informative than a native core file.
I'd also accept that we might want to look at ways to derive the same
information for a core file that wasn't generated by GDB.
I'd be happy for both mechanisms to co-exist.
Others might disagree - I'm happy with that too :)
After some thought though, I have made one change to this patch. In
the version below the target description is generated with a note name
of 'GDB' instead of 'CORE'. This is then checked when the note is
read back in.
This should (hopefully) prevent conflicts in the future, if the note
type (0xff000000) is ever reused by some other core file producer.
Thanks,
Andrew
---
commit 9101b8a935dfe716fd978ef3e47624d0f8956582
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date: Fri Nov 27 15:41:37 2020 +0000
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.
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.
The new note is given the name 'GDB' and a type NT_GDB_TDESC. This
should hopefully protect us if there's ever a reuse of the number
assigned to NT_GDB_TDESC by some other core file producer. It should
also, hopefully, make it clearer to users that this note carries GDB
specific information.
bfd/ChangeLog:
* elf-bfd.h (elfcore_write_gdb_tdesc): Declare new function.
* elf.c (elfcore_grok_gdb_tdesc): New function.
(elfcore_grok_note): Handle NT_GDB_TDESC.
(elfcore_write_gdb_tdesc): New function.
(elfcore_write_register_note): Handle NT_GDB_TDESC.
binutils/ChangeLog:
* readelf.c (get_note_type): Handle NT_GDB_TDESC.
include/ChangeLog:
* elf/common.h (NT_GDB_TDESC): Define.
diff --git a/bfd/elf-bfd.h b/bfd/elf-bfd.h
index 15206b4e876..4dce8114c0f 100644
--- a/bfd/elf-bfd.h
+++ b/bfd/elf-bfd.h
@@ -2797,6 +2797,8 @@ extern char *elfcore_write_aarch_pauth
(bfd *, char *, int *, const void *, int);
extern char *elfcore_write_arc_v2
(bfd *, char *, int *, const void *, int);
+extern char *elfcore_write_gdb_tdesc
+ (bfd *, char *, int *, const void *, int);
extern char *elfcore_write_lwpstatus
(bfd *, char *, int *, long, int, const void *);
extern char *elfcore_write_register_note
diff --git a/bfd/elf.c b/bfd/elf.c
index 84a5d942817..5b1adf17d8d 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -9912,6 +9912,12 @@ elfcore_grok_arc_v2 (bfd *abfd, Elf_Internal_Note *note)
return elfcore_make_note_pseudosection (abfd, ".reg-arc-v2", note);
}
+static bfd_boolean
+elfcore_grok_gdb_tdesc (bfd *abfd, Elf_Internal_Note *note)
+{
+ return elfcore_make_note_pseudosection (abfd, ".gdb-tdesc", note);
+}
+
#if defined (HAVE_PRPSINFO_T)
typedef prpsinfo_t elfcore_psinfo_t;
#if defined (HAVE_PRPSINFO32_T) /* Sparc64 cross Sparc32 */
@@ -10570,6 +10576,13 @@ elfcore_grok_note (bfd *abfd, Elf_Internal_Note *note)
else
return TRUE;
+ case NT_GDB_TDESC:
+ if (note->namesz == 4
+ && strcmp (note->namedata, "GDB") == 0)
+ return elfcore_grok_gdb_tdesc (abfd, note);
+ else
+ return TRUE;
+
case NT_PRPSINFO:
case NT_PSINFO:
if (bed->elf_backend_grok_psinfo)
@@ -11951,6 +11964,18 @@ elfcore_write_arc_v2 (bfd *abfd,
note_name, NT_ARC_V2, arc_v2, size);
}
+char *
+elfcore_write_gdb_tdesc (bfd *abfd,
+ char *buf,
+ int *bufsiz,
+ const void *tdesc,
+ int size)
+{
+ const char *note_name = "GDB";
+ return elfcore_write_note (abfd, buf, bufsiz,
+ note_name, NT_GDB_TDESC, tdesc, size);
+}
+
char *
elfcore_write_register_note (bfd *abfd,
char *buf,
@@ -12035,6 +12060,8 @@ elfcore_write_register_note (bfd *abfd,
return elfcore_write_aarch_pauth (abfd, buf, bufsiz, data, size);
if (strcmp (section, ".reg-arc-v2") == 0)
return elfcore_write_arc_v2 (abfd, buf, bufsiz, data, size);
+ if (strcmp (section, ".gdb-tdesc") == 0)
+ return elfcore_write_gdb_tdesc (abfd, buf, bufsiz, data, size);
return NULL;
}
diff --git a/binutils/readelf.c b/binutils/readelf.c
index 5df51086226..feb458877c8 100644
--- a/binutils/readelf.c
+++ b/binutils/readelf.c
@@ -18296,6 +18296,8 @@ get_note_type (Filedata * filedata, unsigned e_type)
return _("NT_PRPSINFO (prpsinfo structure)");
case NT_TASKSTRUCT:
return _("NT_TASKSTRUCT (task structure)");
+ case NT_GDB_TDESC:
+ return _("NT_GDB_TDESC (GDB XML target description)");
case NT_PRXFPREG:
return _("NT_PRXFPREG (user_xfpregs structure)");
case NT_PPC_VMX:
diff --git a/include/elf/common.h b/include/elf/common.h
index e7d55ae0782..e6e9c278faa 100644
--- a/include/elf/common.h
+++ b/include/elf/common.h
@@ -677,6 +677,10 @@
#define NT_SIGINFO 0x53494749 /* Fields of siginfo_t. */
#define NT_FILE 0x46494c45 /* Description of mapped files. */
+/* The range 0xff000000 to 0xffffffff is set aside for notes that don't
+ originate from any particular operating system. */
+#define NT_GDB_TDESC 0xff000000 /* Contains copy of GDB's target description XML. */
+
/* Note segments for core files on dir-style procfs systems. */
#define NT_PSTATUS 10 /* Has a struct pstatus */
More information about the Binutils
mailing list