[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 16:24:21 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12

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   
    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.


reply via email to

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