Neo,
Thanks for the explanation - I've modified my gdbstub to inspect xPSR
and if STKALIGN is set then "unalign" the stack pointer. With this
change I'm able to inspect threads and unwind callstacks from the
captured Nuttx-12.6 crash dumps.
I'll look at creating a patch to threads.py to handle this(after
figuring out if gdb is debugging ARM).
Again, thanks!
On 1/24/25 12:33, Xu Neo wrote:
It turns out the issue comes from the wrong SP register value getting
restored by python script.
TLDR, If you happen to met that GDB cannot unwind correctly, try set
$sp=$sp+4
The issue is that when an exception happened, armv7-m could push 4 bytes to
stack, to make sure SP is 8bytes aligned.
See
https://developer.arm.com/documentation/ddi0403/d/System-Level-Architecture/System-Level-Programmers--Model/ARMv7-M-exception-model/Stack-alignment-on-exception-entry
It happens that NuttX release 12.6.0 generates code that has SP not aligned
to 4 bytes as shown below, right before triggering SVC.
[image: img_v3_02is_bcd2a515-ec2b-4432-a86a-cbd232cb736l.jpeg]
According to the documentation, we can distinguish this situation from
xPSR[9] bit. xPSR is pushed to stack automatically.
[image: img_v3_02is_e29e799d-75c4-4520-b145-a2369b4b5ael.jpeg]
In this case, the real SP after restore should be `SP + 4`. After
adjusting it manually, now GDB can unwind correctly.
[image: a8GxTXm0aT.jpeg]
NuttX release 12.8.0 changes the sys_call to macro, which saves 4 bytes on
stack, avoiding this issue (coincidently?). The latest master branch does
not have this issue too, and I’m not sure if it’s guaranteed or not.
Regards,
Neo
--
Peter Barada
peter.bar...@gmail.com
