|
From: | Ken Werner |
Subject: | Re: [Libunwind-devel] unwinding from signal handler (ARM) |
Date: | Tue, 30 Aug 2011 09:48:58 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 |
On 08/29/2011 06:11 PM, Ken Werner wrote:
On 08/29/2011 04:24 PM, Ken Werner wrote:On 08/22/2011 11:41 AM, Sven Neumann wrote:Hi, 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 _startThe 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_handlerHm, 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. : )
These two small patches improve the situation in my system: http://lists.nongnu.org/archive/html/libunwind-devel/2011-08/msg00059.htmlYou'll need to enable either the -g or the -funwind-tables GCC switch (or both) for the code you want to unwind. Unwinding mixed stack frames should work too. In case the UNW_ARM_UNWIND_METHOD environment variable doesn't restrict libunwind to use a certain unwind method it tries to use DWARF info first and falls back to use the ARM specific unwind tables.
Regards Ken
[Prev in Thread] | Current Thread | [Next in Thread] |