gdb/riscv: introduce bare metal core dump support
authorAndrew Burgess <andrew.burgess@embecosm.com>
Mon, 30 Nov 2020 12:15:08 +0000 (12:15 +0000)
committerAndrew Burgess <andrew.burgess@embecosm.com>
Fri, 5 Mar 2021 17:21:41 +0000 (17:21 +0000)
commitfb8f3fc0c3c4d04856547fddb86d7c9dabef681b
tree4004e4486f4e20b65b869b4f65686f3e08454f19
parent0897bb7d6dc4e803cd99d4656186c965f099d01c
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.
gdb/ChangeLog
gdb/Makefile.in
gdb/configure
gdb/configure.ac
gdb/configure.tgt
gdb/elf-none-tdep.c [new file with mode: 0644]
gdb/elf-none-tdep.h [new file with mode: 0644]
gdb/riscv-none-tdep.c [new file with mode: 0644]
This page took 0.026846 seconds and 4 git commands to generate.