How to get a stack trace in RTEMS

--===============2965572260581129916==
Content-Type: multipart/alternative; boundary="0000000000001a79ff061bc7750b"

--0000000000001a79ff061bc7750b
Content-Type: text/plain; charset="UTF-8"

Dear RTEMS community,

My colleague George cannot register to post to this forum, getting 403 when
subscribing at https://lists.rtems.org/mailman/listinfo/users. I am posting
this question on his behalf.

---

We are currently seeing an RTEMS_FATAL_SOURCE_EXCEPTION right at the start
of execution and can debug the program once the exception handler has been
reached. From here we can inspect the call stack however we only see the
trace that led to the final function call (void bsp_reset(void) while loop)
that handles the exception, not the trace that caused the exception. We
would like to implement an exception handler that prints the trace that
caused the exception to be triggered. Is this something that is already
implemented in RTEMS? We have developed an RTEMS port to the Zynq
UltraScale+ MPSoC Cortex R5 RPU running in lockstep. Code execution is from
the shared DDR4 memory with a 256MB region allocated.

What we want is to have the actual stack trace to be printed to the console.

Here is an example of what we have now in GDB:

bsp_reset@0x0017b062
(.../rtems/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c:40)
_User_extensions_Iterate@0x00186854
(.../rtems/cpukit/score/src/userextiterate.c:194)
_User_extensions_Fatal@0x00183108
(.../rtems/cpukit/include/rtems/score/userextimpl.h:467)
_Terminate@0x00183108 (.../rtems/cpukit/score/src/interr.c:55)
rtems_fatal@0x0018adc2 (.../rtems/cpukit/include/rtems/fatal.h:160)
_ARM_Exception_default@0x0018adc2
(.../rtems/cpukit/score/cpu/arm/arm-exception-default.c:37)
save_more_context@0x00186cfc
(.../rtems/cpukit/score/cpu/arm/armv4-exception-default.S:176)

This is currently what is printed on the serial port:

*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)

R0   = 0x00000056 R8  = 0x00ac8aec
R1   = 0xf000e3a0 R9  = 0x00ac8a5c
R2   = 0x00000020 R10 = 0x00000000
R3   = 0x00000020 R11 = 0x00000000
R4   = 0x00000056 R12 = 0x010e6630
R5   = 0x010e67c0 SP  = 0x010e65d4
R6   = 0x010e6698 LR  = 0x001854ae
R7   = 0x001867f5 PC  = 0x001854ae
CPSR = 0x200f01f7 VEC = 0x00000004
RTEMS version: 6.0.0.62f15c07482dd953663143554e78b4bf287ccb83
RTEMS tools: 12.2.1 20230224 (RTEMS 6, RSB
4c73a76c802588d3864c64ee4dd48a84b953201a, Newlib 17ac400)

---

Thanks,
Stanislav Pankevich, Reflex Aerospace GmbH

--0000000000001a79ff061bc7750b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dear RTEMS community,<br><br>My colleague George cannot re=
gister to post to this forum, getting 403 when subscribing at <a href=3D"ht=
tps://lists.rtems.org/mailman/listinfo/users">https://lists.rtems.org/mailm=
an/listinfo/users</a>. I am posting this question on his behalf.<br><br>---=
<br><br>We are currently seeing an RTEMS_FATAL_SOURCE_EXCEPTION right at th=
e start of execution and can debug the program once the exception handler h=
as been reached. From here we can inspect the call stack however we only se=
e the trace that led to the final function call (void bsp_reset(void) while=
 loop) that handles the exception, not the trace that caused the exception.=
 We would like to implement an exception handler that prints the trace that=
 caused the exception to be triggered. Is this something that is already im=
plemented in RTEMS? We have developed an RTEMS port to the Zynq UltraScale+=
 MPSoC Cortex R5 RPU running in lockstep. Code execution is from the shared=
 DDR4 memory with a 256MB region allocated.<br><br>What we want is to have =
the actual stack trace to be printed to the console.<br><br>Here is an exam=
ple of what we have now in GDB:<br><br>bsp_reset@0x0017b062 (.../rtems/bsps=
/arm/xilinx-zynqmp-rpu/start/bspreset.c:40)<br>_User_extensions_Iterate@0x0=
0186854 (.../rtems/cpukit/score/src/userextiterate.c:194)<br>_User_extensio=
ns_Fatal@0x00183108 (.../rtems/cpukit/include/rtems/score/userextimpl.h:467=
)<br>_Terminate@0x00183108 (.../rtems/cpukit/score/src/interr.c:55)<br>rtem=
s_fatal@0x0018adc2 (.../rtems/cpukit/include/rtems/fatal.h:160)<br>_ARM_Exc=
eption_default@0x0018adc2 (.../rtems/cpukit/score/cpu/arm/arm-exception-def=
ault.c:37)<br>save_more_context@0x00186cfc (.../rtems/cpukit/score/cpu/arm/=
armv4-exception-default.S:176)<br><br>This is currently what is printed on =
the serial port:<br><br>*** FATAL ***<br>fatal source: 9 (RTEMS_FATAL_SOURC=
E_EXCEPTION)<br><br>R0 =C2=A0 =3D 0x00000056 R8 =C2=A0=3D 0x00ac8aec<br>R1 =
=C2=A0 =3D 0xf000e3a0 R9 =C2=A0=3D 0x00ac8a5c<br>R2 =C2=A0 =3D 0x00000020 R=
10 =3D 0x00000000<br>R3 =C2=A0 =3D 0x00000020 R11 =3D 0x00000000<br>R4 =C2=
=A0 =3D 0x00000056 R12 =3D 0x010e6630<br>R5 =C2=A0 =3D 0x010e67c0 SP =C2=A0=
=3D 0x010e65d4<br>R6 =C2=A0 =3D 0x010e6698 LR =C2=A0=3D 0x001854ae<br>R7 =
=C2=A0 =3D 0x001867f5 PC =C2=A0=3D 0x001854ae<br>CPSR =3D 0x200f01f7 VEC =
=3D 0x00000004<br>RTEMS version: 6.0.0.62f15c07482dd953663143554e78b4bf287c=
cb83<br>RTEMS tools: 12.2.1 20230224 (RTEMS 6, RSB 4c73a76c802588d3864c64ee=
4dd48a84b953201a, Newlib 17ac400)<br><br>---<br><br>Thanks,<br>Stanislav Pa=
nkevich, Reflex Aerospace GmbH</div>

--0000000000001a79ff061bc7750b--

--===============2965572260581129916==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
users mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/users
--===============2965572260581129916==--