On 08/22/2011 11:41 AM, Sven Neumann wrote:
Hi,
On Fri, 2011-08-19 at 17:24 +0200, Ken Werner wrote:
Attached is a simple testcase that works on my PandaBoard. How does it
look on your system? The output should look like this:
standard frame ip: 0x8988, sp: 0xbeffadd0 sig_handler
signal frame ip: 0x40113740, sp: 0xbefff2f0
__default_rt_sa_restorer_v2
standard frame ip: 0x8c4e, sp: 0xbefff660 main
standard frame ip: 0x40104623, sp: 0xbefff668 __libc_start_main
standard frame ip: 0x88b7, sp: 0xbefff7a8 _start
The test-case works for me as well and it seems that the compiler flags
are what make it work. We used to use the --enable-debug-frames option
with libunwind and compiled our software stack with "-g1" in order to
get executables with debug frames. We did not use -funwind-tables
though. As far as I understand libunwind did not support those on the
ARM platform back then.
So with -funwind-tables your test-case results in this output:
standard frame ip: 0x89d4, sp: 0xbed59308 sig_handler
signal frame ip: 0x400fb5fc, sp: 0xbed5d7a0 __default_rt_sa_restorer
standard frame ip: 0x8990, sp: 0xbed5db10 main
standard frame ip: 0x401352f4, sp: 0xbed5db88 __uClibc_main
And without it, it isn't able to unwind:
standard frame ip: 0x88e8, sp: 0xbed18308 sig_handler
Hm, this shouldn't happen. If there is DWARF info libunwind should be
able to find it and properly unwind the stack. I'll have a look into this.
Regards
Ken
_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
