libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] Re: [PATCH 0/4] ARM enhancements


From: Ken Werner
Subject: Re: [Libunwind-devel] Re: [PATCH 0/4] ARM enhancements
Date: Tue, 29 Mar 2011 11:17:22 +0200
User-agent: KMail/1.13.5 (Linux/2.6.35-28-generic-pae; KDE/4.5.1; i686; ; )

On Tuesday, March 29, 2011 9:04:58 am Henrik Grindal Bakken wrote:
> Ken Werner <address@hidden>
> 
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]