[Top][All Lists]

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

Re: [Libunwind-devel] status of ARM support

From: andris.zeila
Subject: Re: [Libunwind-devel] status of ARM support
Date: Tue, 3 Aug 2010 14:11:41 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6

On 2010-08-03 14:56, Sven Neumann wrote:
> On Tue, 2010-08-03 at 13:50 +0200, address@hidden wrote:
>   >  >  I didn't add these extra options, and of course I would prefer if I
>   >  >  wouldn't have to. So far I have tried to add -funwind-tables, but that
>   >  >  did not seem to help with dwarf_step().
>   >  >
>   >
>   >  No, it won't. Libunwind (at least on ARM) requires .debug_frame for
>   >  dwarf_step() to work. You can check if your binary contains .debug_frame
>   >  (objdump -h<binary>  | grep debug_frame).
>   >  If not you can try compiling with -g1 and see what happens.
> Yes, I found that compiling with -g1 makes everything work nicely.
> Thanks for your help.
> Of course the binaries and libraries compiled with -g1 are a good deal
> larger than what we used to use. On the other hand we now get reasonable
> backtraces. Is there anything I could strip from the binaries and
> libraries built with -g1 without breaking libunwind again?

Alternatively you could try enabling the -mapcs-frame and 
and check if the frame chain based unwinding works. If it does - the binaries/
libraries should be smaller than compiled with -g1.

This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.

reply via email to

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