Task context information available on crash

[Chris Johns]

On 20/03/2018 04:36, Matthew J Fletcher wrote:
> 
> When an application crashes and the bsp_fatal_extension() is invoked, is there a
> way to see (in gdb or otherwise) what the last executing task was ?
> 
> I guess there is some task context maintained but it would be internal to rtems.
> 

Can I assume by crash you mean some form of exception being generated as a
result of a bad access, corrupted stack, corrupted code, or something else?

When in GDB getting back to the instruction that causes an exception with a
valid backtrace depends on the architecture you are using as well as the way you
are debugging, eg JTAG, type of debugger, etc. At a low level on a x86 it is
easy and on an ARM is harder.

I see from previous posts you are using a Cortex-M7 and on these types of ARMs
getting back to the task's context from the exception's first instruction
requires some low level smarts. It is possible and is what libdebugger does [1].
The libdebugger code is much more complicated than a simple switch because it
does this while running in an RTEMS environment and the system has to stay up
and running do the network stack can work. On a CortexA9 like a Zynq a crash
when running libdebugger places you at the instruction with correct registers
values and a working backtrace. It is a nice feature to have, plus you can list
all threads and thread states and switch to other threads and view their backtrace.

To do it in GDB without libdebugger's support you need to switch the stack
pointer back to the task's stack and adjust the stack frame removing anything
added by the exception. I have not looked into doing this in GDB and if GDB
correctly tracks the selected stack register after forcing a switch which you
need to change the context.

Chris

[1] https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-arm.c#n732