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

[Ken Werner]

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 _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. : )

Regards
Ken