Re: How to get a stack trace in RTEMS
Stanislav Pankevich <[email protected]> Wed, 26 Jun 2024 16:14:39 +0200
| Newsgroups | gmane.os.rtems.user |
|---|---|
| Message-ID | <CAFXpGYZLQz9GfFQAE_thKRfW7X5nmyH9WrvQJdhdH4M2nA7JkQ@mail.gmail.com> |
--===============7149215449415378452==
Content-Type: multipart/alternative; boundary="000000000000352abb061bcba382"
--000000000000352abb061bcba382
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Sebastian,
We had to add -funwind-tables to have this trace() called, and we can now
see the function names as follows. The challenge is that the functions of
the exception handler are printed, not the code that led to the exception.
Now we need to figure out how to switch this code to print our function
names instead.
FUNC NAME: bsp_fatal_extension
FUNC NAME: _User_extensions_Iterate
FUNC NAME: _Terminate
FUNC NAME: _ARM_Exception_default
static _Unwind_Reason_Code trace(_Unwind_Context *ctx, void *arg)
{
(void)arg;
const uint32_t func_entry =3D _Unwind_GetRegionStart(ctx);
char *func_name =3D "??";
uint8_t *canary =3D (uint8_t *)(func_entry - 0x4);
const uint32_t len =3D (*((uint32_t *)(func_entry - 0x4))) &
0x00FFFFFF;
if (*canary =3D=3D 0xFF)
{
func_name =3D (char *)((uint32_t)canary - len);
*canary =3D '\0';
}
printk("FUNC NAME: %s\n", func_name);
return _URC_NO_REASON;
}
Thanks,
Stanislav Pankevich
On Wed, Jun 26, 2024 at 11:25=E2=80=AFAM Sebastian Huber <
sebastian.huber-L1vi/[email protected]> wrote:
> Hello Stanislav,
>
> On 26.06.24 11:15, Stanislav Pankevich wrote:
> > 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
> > <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.
>
> I have some improvements for this BSP in my patch queue. It adds support
> for the split mode for example.
>
> >
> > 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 =3D 0x00000056 R8 =3D 0x00ac8aec
> > R1 =3D 0xf000e3a0 R9 =3D 0x00ac8a5c
> > R2 =3D 0x00000020 R10 =3D 0x00000000
> > R3 =3D 0x00000020 R11 =3D 0x00000000
> > R4 =3D 0x00000056 R12 =3D 0x010e6630
> > R5 =3D 0x010e67c0 SP =3D 0x010e65d4
> > R6 =3D 0x010e6698 LR =3D 0x001854ae
> > R7 =3D 0x001867f5 PC =3D 0x001854ae
> > CPSR =3D 0x200f01f7 VEC =3D 0x00000004
> > RTEMS version: 6.0.0.62f15c07482dd953663143554e78b4bf287ccb83
> > RTEMS tools: 12.2.1 20230224 (RTEMS 6, RSB
> > 4c73a76c802588d3864c64ee4dd48a84b953201a, Newlib 17ac400)
>
> Getting stack traces on arm is not that easy since you need a
> description of the stack frames. You can try to use the unwinder from
> libgcc:
>
> static _Unwind_Reason_Code trace(_Unwind_Context *ctx, void *arg)
> {
> (void)arg;
> printk("%08" PRIuPTR "\n", (uintptr_t)_Unwind_GetIP(ctx));
> return _URC_NO_REASON;
> }
>
> static void f(int i);
>
> static void h(int i)
> {
> f(i + 1);
> }
>
> static void f(int i)
> {
> if (i > 10) {
> _Unwind_Backtrace(trace, NULL);
> } else {
> h(i + 1);
> }
> }
>
> --
> embedded brains GmbH & Co. KG
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber-L1vi/[email protected]
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht M=C3=BCnchen
> Registernummer: HRB 157899
> Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas=
D=C3=B6rfler
> Unsere Datenschutzerkl=C3=A4rung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
--000000000000352abb061bcba382
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Sebastian,</div><div><br></div><div>We had to add =
-funwind-tables to have this trace() called, and we can now see the functio=
n names as follows. The challenge is that the functions of the exception ha=
ndler are printed, not the code that led to the exception. Now we need to f=
igure out how to switch this code to print our function names instead.<br><=
/div><div><br></div><div>FUNC NAME: bsp_fatal_extension<br>FUNC NAME: _User=
_extensions_Iterate<br>FUNC NAME: _Terminate<br>FUNC NAME: _ARM_Exception_d=
efault<br><br></div><div>static _Unwind_Reason_Code trace(_Unwind_Context *=
ctx, void *arg)<br>{<br>=C2=A0 =C2=A0 (void)arg;<br><br>=C2=A0 =C2=A0 const=
uint32_t func_entry =C2=A0=3D _Unwind_GetRegionStart(ctx);<br><br>=C2=A0 =
=C2=A0 char =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*func_name =3D "??"=
;<br>=C2=A0 =C2=A0 uint8_t =C2=A0 =C2=A0 =C2=A0 *canary =C2=A0 =C2=A0=3D (u=
int8_t *)(func_entry - 0x4);<br>=C2=A0 =C2=A0 const uint32_t len =C2=A0 =C2=
=A0 =C2=A0 =3D (*((uint32_t *)(func_entry - 0x4))) & 0x00FFFFFF;<br>=C2=
=A0 =C2=A0 if (*canary =3D=3D 0xFF)<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 func_name =3D (char *)((uint32_t)canary - len);<br>=C2=A0 =C2=A0=
=C2=A0 =C2=A0 *canary =C2=A0 =3D '\0';<br>=C2=A0 =C2=A0 }<br>=C2=
=A0 =C2=A0 printk("FUNC NAME: %s\n", func_name);<br><br>=C2=A0 =
=C2=A0 return _URC_NO_REASON;<br>}</div><div><br></div><div>Thanks,</div><d=
iv>Stanislav Pankevich<br></div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 26, 2024 at 11:25=E2=80=AFAM Se=
bastian Huber <<a href=3D"mailto:sebastian.huber-L1vi/[email protected]">seb=
astian.huber-L1vi/[email protected]</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Hello Stanislav,<br>
<br>
On 26.06.24 11:15, Stanislav Pankevich wrote:<br>
> Dear RTEMS community,<br>
> <br>
> My colleague George cannot register to post to this forum, getting 403=
<br>
> when subscribing at <a href=3D"https://lists.rtems.org/mailman/listinf=
o/users" rel=3D"noreferrer" target=3D"_blank">https://lists.rtems.org/mailm=
an/listinfo/users</a> <br>
> <<a href=3D"https://lists.rtems.org/mailman/listinfo/users" rel=3D"=
noreferrer" target=3D"_blank">https://lists.rtems.org/mailman/listinfo/user=
s</a>>. I am posting this <br>
> question on his behalf.<br>
> <br>
> ---<br>
> <br>
> We are currently seeing an RTEMS_FATAL_SOURCE_EXCEPTION right at the <=
br>
> start of execution and can debug the program once the exception handle=
r <br>
> has been reached. From here we can inspect the call stack however we <=
br>
> only see the trace that led to the final function call (void <br>
> bsp_reset(void) while loop) that handles the exception, not the trace =
<br>
> that caused the exception. We would like to implement an exception <br=
>
> handler that prints the trace that caused the exception to be triggere=
d. <br>
> Is this something that is already implemented in RTEMS? We have <br>
> developed an RTEMS port to the Zynq UltraScale+ MPSoC Cortex R5 RPU <b=
r>
> running in lockstep. Code execution is from the shared DDR4 memory wit=
h <br>
> a 256MB region allocated.<br>
<br>
I have some improvements for this BSP in my patch queue. It adds support <b=
r>
for the split mode for example.<br>
<br>
> <br>
> What we want is to have the actual stack trace to be printed to the co=
nsole.<br>
> <br>
> Here is an example of what we have now in GDB:<br>
> <br>
> bsp_reset@0x0017b062 <br>
> (.../rtems/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c:40)<br>
> _User_extensions_Iterate@0x00186854 <br>
> (.../rtems/cpukit/score/src/userextiterate.c:194)<br>
> _User_extensions_Fatal@0x00183108 <br>
> (.../rtems/cpukit/include/rtems/score/userextimpl.h:467)<br>
> _Terminate@0x00183108 (.../rtems/cpukit/score/src/interr.c:55)<br>
> rtems_fatal@0x0018adc2 (.../rtems/cpukit/include/rtems/fatal.h:160)<br=
>
> _ARM_Exception_default@0x0018adc2 <br>
> (.../rtems/cpukit/score/cpu/arm/arm-exception-default.c:37)<br>
> save_more_context@0x00186cfc <br>
> (.../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_SOURCE_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 R10 =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.62f15c07482dd953663143554e78b4bf287ccb83<br>
> RTEMS tools: 12.2.1 20230224 (RTEMS 6, RSB <br>
> 4c73a76c802588d3864c64ee4dd48a84b953201a, Newlib 17ac400)<br>
<br>
Getting stack traces on arm is not that easy since you need a <br>
description of the stack frames. You can try to use the unwinder from <br>
libgcc:<br>
<br>
static _Unwind_Reason_Code trace(_Unwind_Context *ctx, void *arg)<br>
{<br>
=C2=A0 =C2=A0(void)arg;<br>
=C2=A0 =C2=A0printk("%08" PRIuPTR "\n", (uintptr_t)_Unw=
ind_GetIP(ctx));<br>
=C2=A0 =C2=A0return _URC_NO_REASON;<br>
}<br>
<br>
static void f(int i);<br>
<br>
static void h(int i)<br>
{<br>
=C2=A0 =C2=A0f(i + 1);<br>
}<br>
<br>
static void f(int i)<br>
{<br>
=C2=A0 =C2=A0if (i > 10) {<br>
=C2=A0 =C2=A0 =C2=A0_Unwind_Backtrace(trace, NULL);<br>
=C2=A0 =C2=A0} else {<br>
=C2=A0 =C2=A0 =C2=A0 h(i + 1);<br>
=C2=A0 =C2=A0}<br>
}<br>
<br>
-- <br>
embedded brains GmbH & Co. KG<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href=3D"mailto:sebastian.huber-L1vi/[email protected]" target=3D"_bla=
nk">sebastian.huber-L1vi/[email protected]</a><br>
phone: +49-89-18 94 741 - 16<br>
fax:=C2=A0 =C2=A0+49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht M=C3=BCnchen<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas D=
=C3=B6rfler<br>
Unsere Datenschutzerkl=C3=A4rung finden Sie hier:<br>
<a href=3D"https://embedded-brains.de/datenschutzerklaerung/" rel=3D"norefe=
rrer" target=3D"_blank">https://embedded-brains.de/datenschutzerklaerung/</=
a><br>
</blockquote></div>
--000000000000352abb061bcba382--
--===============7149215449415378452==
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
--===============7149215449415378452==--