Why was debug_coredump deleted?

General
1

The documentation has an Analysing core dumps section that references running make debug_coredump, but that was deleted in cesanta/mongoose-os@9164e8a82. The comment isn’t very helpful: “Delete some junk along the way”. Was this intentional? Is there a new way to debug core dumps?

2

That section is outdated.
If you use mos build --local (docker is needed) and run mos console in the root directory of your firmware, the core dump will be analysed automatically by mos.

3

Thanks @nliviu, I’ll submit a pull request to update the documentation. I am doing a local build, and it doing a backtrace in gdb, as you suggested (thanks). However, the stack is basically empty. Is there a way to build with debug symbols?

[Sep  7 12:45:52.981] SW WDT @ 0x40002ef1
[Sep  7 12:45:52.983]  A0: 0x40002ef1  A1: 0x3ffff9e0  A2: 0x2c954987  A3: 0x00000015
[Sep  7 12:45:52.988]  A4: 0x019df0e1  A5: 0x000000ff  A6: 0x3ffef6d4  A7: 0x00000000
[Sep  7 12:45:52.994]  A8: 0x0000002b  A9: 0x00000170 A10: 0x00000005 A11: 0x00000020
[Sep  7 12:45:53.000] A12: 0x01e84800 A13: 0x2af7589a A14: 0x40200778 A15: 0x05defda0
[Sep  7 12:45:53.005]
[Sep  7 12:45:53.005] (exc SP: 0x3ffff7b0)
[Sep  7 12:45:53.007]
[Sep  7 12:45:53.007] --- BEGIN CORE DUMP ---
[Sep  7 12:45:53.010] mos: catching core dump
[Sep  7 12:45:55.856] ....
[Sep  7 12:46:04.562] ---- END CORE DUMP ----
[Sep  7 12:46:04.568] mos: wrote to /home/chris/src/si470x_examples/core-si470x_examples-esp8266-20200907-124604.098976141 (133144 bytes)
[Sep  7 12:46:04.568] mos: analyzing core dump
Core dump by si470x_examples/esp8266 0.7 20200907-194541/g37d3565-master-dirty
Using ELF file at: /home/chris/src/si470x_examples/build/objs/si470x_examples.elf
Using Docker image: docker.io/mgos/esp8266-build:2.2.x_a0b13112-r8
Running docker run --rm -v /home/chris/src/si470x_examples/build/objs/si470x_examples.elf:/fw.elf -v /home/chris/src/si470x_examples/core-si470x_examples-esp8266-20200907-124604.098976141:/core -v /home/chris/src/si470x_examples:/home/chris/src/si470x_examples docker.io/mgos/esp8266-build:2.2.x_a0b13112-r8 bash -c /usr/local/bin/serve_core.py --rom=/opt/Espressif/rom/rom.bin --rom_addr=0x40000000 /fw.elf /core & $MGOS_TARGET_GDB /fw.elf -ex 'target remote 127.0.0.1:1234' -ex 'set confirm off' -ex bt -ex quit
GNU gdb (crosstool-NG UNKNOWN) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=xtensa-lx106-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /fw.elf...
Remote debugging using 127.0.0.1:1234
0x40002ef1 in ?? ()
#0  0x40002ef1 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Detaching from program: /fw.elf, Remote target
Ending remote debugging.
4

Is there any way to analyze stored coredumps, like core-test123-esp32-20201201-100232.435013846 ?

5 
mos debug-core-dump core-xxxx

in the root directory of your application.