gdb/arm: add support for bare-metal core dumps
authorAndrew Burgess <andrew.burgess@embecosm.com>
Wed, 20 Jan 2021 15:13:16 +0000 (15:13 +0000)
committerAndrew Burgess <andrew.burgess@embecosm.com>
Tue, 1 Jun 2021 08:56:22 +0000 (09:56 +0100)
commit9b715c68e84d93d6671fac661cad391970462ffb
tree34fac448ae1e730034ce7d51b693ceaeb7d070b4
parentb4b3e2dee20dcde6eb47ebdc6231f5d8edf60ff5
gdb/arm: add support for bare-metal core dumps

This commit adds support for bare metal core dumps on the ARM target,
and is based off of this patch submitted to the mailing list:

  https://sourceware.org/pipermail/gdb-patches/2020-October/172845.html

Compared to the version linked above this version is updated to take
account of recent changes to the core dump infrastructure in GDB,
there is now more shared infrastructure for core dumping within GDB,
and also some common bare metal core dumping infrastructure.  As a
result this patch is smaller than the original proposed patch.

Further, the original patch included some unrelated changes to the
simulator that have been removed from this version.

I have written a ChangeLog entry as the original patch was missing
one.

I have done absolutely no testing of this patch.  It is based on the
original submitted patch, which I assume was tested, but after my
modifications things might have been broken, however, the original
patch author has tested this version and reported it as being good:

  https://sourceware.org/pipermail/gdb-patches/2021-May/178900.html

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 2 basic types you would expect in a OS based core dump,
NT_PRPSINFO, NT_PRSTATUS, along with the architecture specific
NT_ARM_VFP note.

The data layouts for each note type are described below, in all cases,
all padding fields should be set to zero.

Note NT_PRPSINFO is optional.  Its data layout is:

  struct prpsinfo_t
  {
    uint8_t padding[28];
    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 prstatus_t
  {
    uint8_t padding_1[12];
    uint16_t sig;
    uint8_t padding_2[10];
    uint32_t thread_id;
    uint8_t padding_3[44];
    uint32_t gregs[18];
  }

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 'gregs' - holds the general purpose registers $a1 through to $pc
    at indices 0 to 15.  At index 16 the program status register.
    Index 17 should be set to zero.

Note NT_ARM_VFP is optional, its data layout is:

  armvfp_t
  {
    uint64_t regs[32];
    uint32_t fpscr;
  }

Field 'regs' - holds the 32 d-registers 0 to 31 in order.

Field 'fpscr' - holds the fpscr register.

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:

PR gdb/14383
* Makefile.in (ALL_TARGET_OBS): Add arm-none-tdep.o.
(ALLDEPFILES): Add arm-none-tdep.c
* arm-none-tdep.c: New file.
* configure.tgt (arm*-*-*): Add arm-none-tdep.o to cpu_obs.
gdb/ChangeLog
gdb/Makefile.in
gdb/arm-none-tdep.c [new file with mode: 0644]
gdb/configure.tgt
This page took 0.026759 seconds and 4 git commands to generate.