[Top][All Lists]
[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
- [Libunwind-devel] [PATCH 2/4] Add module for parsing ARM-specific unwind tables, (continued)