[Top][All Lists]

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

Re: [Libunwind-devel] unwinding from signal handler (ARM)

From: Ken Werner
Subject: Re: [Libunwind-devel] unwinding from signal handler (ARM)
Date: Mon, 29 Aug 2011 18:11:59 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12

On 08/29/2011 04:24 PM, Ken Werner wrote:
On 08/22/2011 11:41 AM, Sven Neumann wrote:

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.

I think I know what's going on. When building without -funwind-tables the binary still contains ARM specific unwind infos because crt1.o gets linked in. So, the resulting binary contains a .ARM.exidx section and libunwind tries to find the corresponding unwing info to the given IP. The .ARM.exidx section contains a (binary searchable) list of function start addresses while the end-address is the next start-address minus one. But in this case there is only one address for the "_start" routine of the crt1.o. So, the end-address is the start-address plus the size of the corresponding text segment. Therefore libunwind will always find the unwind info for the _start routine which says "cantunwind" and therefore unwinding stops after the first frame. I'm not sure if there is a good solution for this. As a workaround you may set the UNW_ARM_UNWIND_METHOD environment variable to "1". Suggestions and patches are welcome. : )


reply via email to

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