As you can see, the back trace process is stuck at dispatch_syscall function
However, xtensa can handle this case correctly by disguising a system call as a regular function call.
In my opinion, the unwind sections about .ARM.extab and.ARM.exidx which are completely different sets of sections in kernel mode file and user mode file. So is it impossible to make backtrace in this case theoretically or is there any way to solve this problem?
xtensa has the special code which adjust the stack layout to make gdb pass through syscall boundary, @tmedicci does extensa trick apply to arm arch too?
Description / Steps to reproduce the issue
build system in protect mode or kernel mode
As you can see, the back trace process is stuck at dispatch_syscall function
However, xtensa can handle this case correctly by disguising a system call as a regular function call.
In my opinion, the unwind sections about .ARM.extab and.ARM.exidx which are completely different sets of sections in kernel mode file and user mode file. So is it impossible to make backtrace in this case theoretically or is there any way to solve this problem?
On which OS does this issue occur?
[OS: Linux]
What is the version of your OS?
ubuntu 18.04 x64
NuttX Version
master
Issue Architecture
[Arch: arm]
Issue Area
[Area: Debugging]
Verification