Today corefiles are only supported by Linux targets for ARM. It would be great to have the possibility to have basic corefiles also for non-Linux ARM targets. The ideal would be to be able to eg. run remote serial GDB to target dev-board and eg. put breakpoints in exception handler, then run 'generate-core-file' to be able to debug it later off-line using core-files from disk. Possibly the existing code for corefiles in in 'arm-linux-tdep.c'. Could this be moved to the more generic 'arm-tdep.c' to enable a default-corefile support that could be overridden when calling osabi_init() ? I submit a patch that seems to work, but more as an example how it could be done perhaps, any other suggestions for solutions are ofcourse welcome.
Created attachment 6544 [details] Idea how it could be done maybe Maybe this is crazy, but I tested it and the patched gdb did accept my corefile. I'm not sure about how gcore running generate-core-file will work as in a none-target there are not known threads nor processes, so I guess it will just be one single dummy process running.
Created attachment 6717 [details] Added new default core file support files to build. Default core file support in separate file.
Created attachment 6718 [details] arm-none-tdep.h
Created attachment 6719 [details] arm-none-tdep.c
I added a solution where Linux core file support was duplicated, separated, and modified to make an independent arm none/bare metal core file feature in GDB. It also works with remote targets, using 'gcore' or 'generate-core-file' command to generate code while debugging. Though in this case all RAM must be setup in sections for linker script. I had to add 'dummy sections' for slack RAM like stacks and other non-linktime defined RAM, example from linker script (0x1000 is max RAM size): .slack_ram (NOLOAD) : { . += (0x1000 - SIZEOF(.data) - SIZEOF(.bss)); } > RAM I will also add simple core file generator code to be able to eg. write all RAM to flash bank while crashing/asserting, to be able at a later stage send core-file-template to PC and at a later stage use a tool to generate a 'real' core. This tool might be put on a separate server. /Fredrik
Hi, this sounds like a wonderful idea! Is there anything I can do to help to get this into GDB? I'm currently developing on ARM Cortex M0 targets. I could test the patch. If someone gives me some pointers, I could write a tool to convert the ram dumps to a real core file. Let me know if there is anything I could do to help. kind regards, Torsten
Created attachment 12903 [details] Patch for GDB-7.11.1 Patch to add corefile support for arm-none-eabi
Added a patch version I made for GDB-7.11.1
Created attachment 12912 [details] Adds corefile support for arm-none-eabi Rebased and updated to GDB 10 master, this patch adds corefile support for arm-none-eabi. Tried to remote target debug my Cortex-M4 board, and successfully did (gdb) gcore testing.core Saved corefile testing.core then later off-line, did debug corefile without target connection locally: $ arm-none-eabi-gdb testing.elf testing.core It worked fine, I could check 'bt' for call-backtrace etc.
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9b715c68e84d93d6671fac661cad391970462ffb commit 9b715c68e84d93d6671fac661cad391970462ffb Author: Andrew Burgess <andrew.burgess@embecosm.com> Date: Wed Jan 20 15:13:16 2021 +0000 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.
ARM bare-metal corefile supported added in GDB-11 release.