add backtrace support when we have a crash

[galak]

[SebastianBoe]

Hi, just my two cents.

Unwinding the stack is tricky.

A halfway solution is to at least run addr2line to get the source code line
that triggered the crash. This will often be good enough.

I saw libunwind was suggested as a way to implement this, I'm not familiar with it,
but one way to do this with the tools we already depend on is to simply connect GDB
and dump the backtrace after the crash.

But both of these techniques would require that we stop running qemu / flasher scripts
directly, but instead use some kind of wrapper script like what marti did with the flashers
(Something we probably want to do longterm anyway).

[andrewboie]

the symbol table is not currently available at runtime, so having comprehensible output without getting GDB into the picture will require solving this in some way.

for most HW platforms, we convert the .elf into a .bin or .hex which has all debug stuff stripped out.

QEMU does get passed a .elf binary to run the kernel, but I haven't seen any easy way for the running kernel to access the elf's debug sections.

what we probably need is some non-default option to include some subset of the symbol table somewhere in the kernel's read-only data section. and then some kind of stack unwinding code to print it out. we don't care about footprint for QEMU targets and could enable this option by default for them.

i know the Linux kernel can do this with dump_stack(), I don't know details, but their approach is probably quite worth looking at.

[galak]

So I wasn't thinking of symbolic info, but at least having the addresses displayed would be useful.

[nashif]

@galak can you provide a more detailed description for this request, this will narrow it down at least.

[andrewboie]

https://github.com/DataAnalysisCosby/blog/blob/master/org/unwind.org

[andrewboie]

https://github.com/CurieBSP/main/blob/master/bsp/src/machine/soc/intel/quark_se/quark/panic.c

[andrewboie]

@lpereira and I were just talking about this.

[lpereira]

FWIW, this has been implemented for x86. The way it works is that it just unwinds the stack while printing out the return address and stack location for the arguments.

It does not try to obtain the symbol table to provide a user-friendly output, but it's possible to use addr2line with the ELF build artifact and locate the offending lines, or maybe peek the memory (with GDB) to try to make some sense out of the arguments pointer. I don't expect the arguments pointer to be terribly useful, though; it's only printed because it was there in the stack frame.

[dleach02]

I'll also add that there is additional debug capabilities that I tend to add in to enable Micro Trace Buffer support in Arm cores that support it. Something to consider because it is useful when you take a fault to be able to look back at the instruction flow that got you where you are...