diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2020-11-27 15:41:52 +0000 |
---|---|---|
committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2021-03-05 17:21:41 +0000 |
commit | 95ce627aeb9df14bdaf70faf67054cb953678797 (patch) | |
tree | 9ccba4435c9e71c6bbc017edd41dcb33542b7e97 /gdb/fbsd-tdep.c | |
parent | b63a5e38efa2dc6df46eafb0bbad3f48472e1bef (diff) | |
download | gdb-95ce627aeb9df14bdaf70faf67054cb953678797.zip gdb-95ce627aeb9df14bdaf70faf67054cb953678797.tar.gz gdb-95ce627aeb9df14bdaf70faf67054cb953678797.tar.bz2 |
gdb: write target description into core file
When a core file is created from within GDB add the target description
into a note within the core file.
When loading a core file, if the target description note is present
then load the target description from the core file.
The benefit of this is that we can be sure that, when analysing the
core file within GDB, that we are using the exact same target
description as was in use at the time the core file was created.
GDB already supports a mechanism for figuring out the target
description from a given corefile; gdbarch_core_read_description.
This new mechanism (GDB adding the target description) is not going to
replace the old mechanism. Core files generated outside of GDB will
not include a target description, and so GDB still needs to be able to
figure out a target description for these files.
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.
I therefore need a mechanism to write out an arbitrary set of
registers, and to then derive a target description from this arbitrary
set when later loading the core file. The obvious approach (I think)
is to just reuse the target description.
Once I'd decided to add support for writing out the target description
I could either choose to make this RISC-V only, or make it generic. I
figure that having the target description in the core file doesn't
hurt, and _might_ be helpful. So that's how I got here, general
support for including the target description in GDB generated core
files.
In previous versions of this patch I added the target description from
generic code (in gcore.c). However, doing this creates a dependency
between GDB's common code and bfd ELF support. As ELF support in gdb
is optional (for example the target x86_64-apple-darwin20.3.0 does not
include ELF support) then having gcore.c require ELF support would
break the GDB build in some cases.
Instead, in this version of the patch, writing the target description
note is done from each specific targets make notes function. Each of
these now calls a common function in gcore-elf.c (which is only linked
in when bfd has ELF support). And so only targets that are ELF based
will call the new function and we can therefore avoid an unconditional
dependency on ELF support.
gdb/ChangeLog:
* corelow.c: Add 'xml-tdesc.h' include.
(core_target::read_description): Load the target description from
the core file when possible.
* fbsd-tdep.c (fbsd_make_corefile_notes): Add target description
note.
* gcore-elf.c: Add 'gdbsupport/tdesc.h' include.
(gcore_elf_make_tdesc_note): New function.
* gcore-elf.h (gcore_elf_make_tdesc_note): Declare.
* linux-tdep.c (linux_make_corefile_notes): Add target description
note.
Diffstat (limited to 'gdb/fbsd-tdep.c')
-rw-r--r-- | gdb/fbsd-tdep.c | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/gdb/fbsd-tdep.c b/gdb/fbsd-tdep.c index dc4278c..170e8f5 100644 --- a/gdb/fbsd-tdep.c +++ b/gdb/fbsd-tdep.c @@ -712,6 +712,9 @@ fbsd_make_corefile_notes (struct gdbarch *gdbarch, bfd *obfd, int *note_size) return NULL; } + /* Include the target description when possible. */ + gcore_elf_make_tdesc_note (obfd, ¬e_data, note_size); + return note_data; } |