aboutsummaryrefslogtreecommitdiff
path: root/gdb/configure
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2020-11-30 12:15:08 +0000
committerAndrew Burgess <andrew.burgess@embecosm.com>2021-03-05 17:21:41 +0000
commitfb8f3fc0c3c4d04856547fddb86d7c9dabef681b (patch)
tree4004e4486f4e20b65b869b4f65686f3e08454f19 /gdb/configure
parent0897bb7d6dc4e803cd99d4656186c965f099d01c (diff)
downloadgdb-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-xgdb/configure3
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