The undefined function may cause the debugger not able to run
properly. Print a "set confirm off" instruction to the beginning of
output file to solve this problem.
(xt-gdb) break _MemErrorVector
Breakpoint 1 at 0x9f180400
(xt-gdb) break _MemoryExceptionVector_text_start
Function "_MemoryExceptionVector_text_start" not defined.
Make breakpoint pending on future shared library load? (y or [n]) run
Please answer y or [n].
...
Signed-off-by: Brent Lu <brent.lu@intel.com>
The gdb script created by coredump-reader has a fixed reset
vector address. This address only works on a subset of supported
SOF platforms and for other platforms, user has to manually fix
the reset address in the gdb script before use.
Modify the script to emit breakpoint for "_MemErrorVector"
symbol. This is not the reset vector, but the simulation will
still be trapped early. The symbol is part of the firmware
binary, so its address can be looked up at runtime.
Also add a second breakpoint for "_MemoryExceptionVector_text_start".
This will cover SOF binaries built with Zephyr as the RTOS.
BugLink: https://github.com/thesofproject/sof/issues/5125
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
On exceptions and panics, the code will reach panic_rewind. That
function will, among the other things it needs to do to dump the info,
will also dump the exception cause (exccause register). This means that
normally coredumps from panics and those from exceptions are
indistinguishable.
In this commit I reserve the maximum value for exccause (63) to signify
that the dump actually came from a panic instead of a hardware
exception. The easiest way I could see that would not duplicate code is
to simply set the exccause register to this reserved value (otherwise it
could be undefined, as it's not initialized at boot).
I also update the core dumper tool to use 63 as the value reserved for
panics instead of 0 (which is IllegalInstructionCause, a valid hardware
exception).
Signed-off-by: Paul Olaru <paul.olaru@nxp.com>
+ coredump-reader changes to use new variable
+ moved dump_stack before arch_dump_regs in panic
Signed-off-by: Adrian Bonislawski <adrian.bonislawski@linux.intel.com>
Guennadi Liakhovetski