|
From: | Ken Werner |
Subject: | Re: [Libunwind-devel] unwinding from signal handler (ARM) |
Date: | Fri, 19 Aug 2011 17:24:54 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 |
On 08/19/2011 04:53 PM, Ken Werner wrote:
On 08/19/2011 02:39 PM, Sven Neumann wrote:Now I've updated libunwind to 1.0-rc1 and this trick doesn't seem to work any longer. The code appears to crash in libunwind if used as above. I had a look at the ARM implementation and found that there is now code that's supposed to unw_step a signal handler. So I tried without our hack and just use unw_getcontext(). Now it doesn't crash any longer, but it also doesn't unwind over the signal handler. All I get is a stack trace like this: 0x4016cde0 logUnwind() from /usr/lib/libraumfeld-1.0.so.0 0x40205654 ?? from /usr/lib/libunwind.so.7 Any ideas what we could do?Hmm, this is interesting. How does your system look like (which libc, kernel version) and are you stepping over RT or non-RT signal frames? It would be helpful if you could share some code that shows the described behavior. In the meanwhile I'll prepare a simple testcase where I'll verify that it's working on my system.
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 _startThe ARMv7 board runs a Linaro evaluation build with a fairly recent Linux kernel and glibc (www.linaro.org/downloads).
Regards KenPS: I'll be on vacation for a few days starting tomorrow - bad timing. But I'll follow the discussion afterwards.
main.c
Description: Text Data
Makefile
Description: Text document
[Prev in Thread] | Current Thread | [Next in Thread] |