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 _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
