diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2020-11-30 12:15:08 +0000 |
---|---|---|
committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2021-03-05 17:21:41 +0000 |
commit | fb8f3fc0c3c4d04856547fddb86d7c9dabef681b (patch) | |
tree | 4004e4486f4e20b65b869b4f65686f3e08454f19 /gdb/configure | |
parent | 0897bb7d6dc4e803cd99d4656186c965f099d01c (diff) | |
download | gdb-fb8f3fc0c3c4d04856547fddb86d7c9dabef681b.zip gdb-fb8f3fc0c3c4d04856547fddb86d7c9dabef681b.tar.gz gdb-fb8f3fc0c3c4d04856547fddb86d7c9dabef681b.tar.bz2 |
gdb/riscv: introduce bare metal core dump support
This commit adds the ability for bare metal RISC-V target to generate
core files from within GDB.
The intended use case is that a user will connect to a remote bare
metal target, debug up to some error condition, then generate a core
file in the normal way using:
(gdb) generate-core-file
This core file can then be used to revisit the state of the remote
target without having to reconnect to the remote target.
The core file creation code is split between two new files. In
elf-none-tdep.c is code for any architecture with the none
ABI (i.e. bare metal) when the BFD library is built with ELF support.
In riscv-none-tdep.c are the RISC-V specific parts. This is where the
regset and regcache_map_entry structures are defined that control how
registers are laid out in the core file. As this file could (in
theory at least) be used for a non-ELF bare metal RISC-V target, the
calls into elf-none-tdep.c are guarded with '#ifdef HAVE_ELF'.
Currently for RISC-V only the x-regs and f-regs (if present) are
written out. In future commits I plan to add support for writing out
the RISC-V CSRs.
The core dump format is based around generating an ELF containing
sections for the writable regions of memory that a user could be
using. Which regions are dumped rely on GDB's existing common core
dumping code, GDB will attempt to figure out the stack and heap as
well as copying out writable data sections as identified by the
original ELF.
Register information is added to the core dump using notes, just as it
is for Linux of FreeBSD core dumps. The note types used consist of
the 3 basic types you would expect in a OS based core dump,
NT_PRPSINFO, NT_PRSTATUS, NT_FPREGSET.
The layout of these notes differs slightly (due to field sizes)
between RV32 and RV64. Below I describe the data layout for each
note. In all cases, all padding fields should be set to zero.
Note NT_PRPSINFO is optional. Its data layout is:
struct prpsinfo32_t /* For RV32. */
{
uint8_t padding[32];
char fname[16];
char psargs[80];
}
struct prpsinfo64_t /* For RV64. */
{
uint8_t padding[40];
char fname[16];
char psargs[80];
}
Field 'fname' - null terminated string consisting of the basename of
(up to the fist 15 characters of) the executable. Any additional
space should be set to zero. If there's no executable name then
this field can be set to all zero.
Field 'psargs' - a null terminated string up to 80 characters in
length. Any additional space should be filled with zero. This
field contains the full executable path and any arguments passed
to the executable. If there's nothing sensible to write in this
field then fill it with zero.
Note NT_PRSTATUS is required, its data layout is:
struct prstatus32_t /* For RV32. */
{
uint8_t padding_1[12];
uint16_t sig;
uint8_t padding_2[10];
uint32_t thread_id;
uint8_t padding_3[44];
uint32_t x_regs[32];
uint8_t padding_4[4];
}
struct prstatus64_t /* For RV64. */
{
uint8_t padding_1[12];
uint16_t sig;
uint8_t padding_2[18];
uint32_t thread_id;
uint8_t padding_3[76];
uint64_t x_regs[32];
uint8_t padding_4[4];
}
Field 'sig' - the signal that stopped this thread. It's implementation
defined what this field actually means. Within GDB this will be
the signal number that the remote target reports as the stop
reason for this thread.
Field 'thread_is' - the thread id for this thread. It's implementation
defined what this field actually means. Within GDB this will be
thread thread-id that is assigned to each remote thread.
Field 'x_regs' - at index 0 we store the program counter, and at
indices 1 to 31 we store x-registers 1 to 31. x-register 0 is not
stored, its value is always zero anyway.
Note NT_FPREGSET is optional, its data layout is:
fpregset32_t /* For targets with 'F' extension. */
{
uint32_t f_regs[32];
uint32_t fcsr;
}
fpregset64_t /* For targets with 'D' extension . */
{
uint64_t f_regs[32];
uint32_t fcsr;
}
Field 'f_regs' - stores f-registers 0 to 31.
Field 'fcsr' - stores the fcsr CSR register, and is always 4-bytes.
The rules for ordering the notes is the same as for Linux. The
NT_PRSTATUS note must come before any other notes about additional
register sets. And for multi-threaded targets all registers for a
single thread should be grouped together. This is because only
NT_PRSTATUS includes a thread-id, all additional register notes after
a NT_PRSTATUS are assumed to belong to the same thread until a
different NT_PRSTATUS is seen.
gdb/ChangeLog:
* Makefile.in (ALL_TARGET_OBS): Add riscv-none-tdep.o.
(ALLDEPFILES): Add riscv-none-tdep.c.
* configure: Regenerate.
* configure.ac (CONFIG_OBS): Add elf-none-tdep.o when BFD has ELF
support.
* configure.tgt (riscv*-*-*): Include riscv-none-tdep.c.
* elf-none-tdep.c: New file.
* elf-none-tdep.h: New file.
* riscv-none-tdep.c: New file.
Diffstat (limited to 'gdb/configure')
-rwxr-xr-x | gdb/configure | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/gdb/configure b/gdb/configure index 4707fd0..4c80350 100755 --- a/gdb/configure +++ b/gdb/configure @@ -17264,7 +17264,8 @@ $as_echo "$gdb_cv_var_elf" >&6; } LDFLAGS=$OLD_LDFLAGS LIBS=$OLD_LIBS if test "$gdb_cv_var_elf" = yes; then - CONFIG_OBS="$CONFIG_OBS elfread.o stap-probe.o dtrace-probe.o gcore-elf.o" + CONFIG_OBS="$CONFIG_OBS elfread.o stap-probe.o dtrace-probe.o \ + gcore-elf.o elf-none-tdep.o" $as_echo "#define HAVE_ELF 1" >>confdefs.h |