On Tuesday, March 29, 2011 9:04:58 am Henrik Grindal Bakken wrote: > Ken Werner <[email protected]> > > writes: > > On Wednesday, March 23, 2011 9:50:05 am Henrik Grindal Bakken wrote: > >> Hi Ken, > >> > >> This patch set works better for me, but I get a crash (SIGSEGV) when > >> trying to get backtrace from a signal handler. I'll try to figure out > >> why... > > > > Hi Henrik > > > > I've hacked a small test but wasn't able to reproduce the segfault on my > > system. Could you share your code or elaborate on what you did? Attached > > is the test case I was using. > > Hi again Ken, > > Trying to reproduce it now, I don't see the same errors I used to. As > long as I remember to add UNW_ARM_UNWIND_METHOD=4 (should this be the > default on arm?)
Since DWARF information is more powerful than the infos provided by the ARM specific unwind tables libunwind tries to unwind using DWARF infos at first and extbl second. If everything fails it falls back on the APCS frame parsing. This behavior can be adjusted by setting the UNW_ARM_UNWIND_METHOD environment variable. The APCS frame parsing may cause segfaults as they are no there on EABI systems. However, if you look at the testresults you'll notice a lot of FAILs and segfaults on ARMv7 gnueabi (extbl and DWARF). These need to be understood and fixed/documented. : ) > , I get a fairly good backtrace from signal handler. > It typically looks like this: > > /tmp/libunwind-test(foo+0x40) [0xaab8] > /lib/libpthread.so.0(_pthread_cleanup_pop_restore+0x1c) [0x402497e4] > /tmp/libunwind-test(main+0x44) [0xabb4] > /lib/libc.so.6(__libc_start_main+0x120) [0x402705e0] > /tmp/libunwind-test() [0xa9e4] > > Where I suppose _pthread_cleanup_pop_restore should've been bar() in > my code, but that's a) not critical, and b) possibly solvable in the > signal handler. Hm, this is interesting. You could run your executable under gdb and compare the addresses (SP, IP/PC) that a gdb backtrace gives with the addresses that libunwind reports. Hint: It seems that GDB strips the thumb marker from the return address so the PC is one byte off (but that shouldn't matter afaik). Regards Ken _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
