[Top][All Lists]

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

Re: [Libunwind-devel] libunwind with LD_PRELOAD option

From: Shan Shan
Subject: Re: [Libunwind-devel] libunwind with LD_PRELOAD option
Date: Wed, 7 Sep 2011 18:29:07 +0100

If there is insufficient unwind data available the result is undefined I guess (I wouldn't expect libunwind to crash though). On modern ARM-Linux systems you'll need either DWARF (-g) or the ARM specific unwind tables (-funwind-tables) to be able to backtrace. The latter takes less space but is not as accurate as DWARF in some corner cases (for example in case an async signal interrupted a prologue or epilogue).

Looking further into the build logs, i can see the App is built with the following compiler options.

-g -Wall -Wno-unknown-pragmas -Os -fno-builtin-fprintf -fno-rtti -fno-exceptions

Finally it is stripped with "-S -g" option so that all debug frame info is gone in the target version. However, even with this, i can still get a unit test app working providing complete backtrace.

The unit test app was earlier crashing. Yesterday i thought it is working because of "-funwind-tables" but today i found that it was one of  my experimentation image. I was trying "-fno-omit-frame-pointer" option and only that version crashed. Actually "-funwind-tables" had 
no effect on the final stripped image. This is because of "fno-exceptions" option i guess :-(

I guess unwinding is not a issue at all at this current stage. If i can find the reason for main App crashing even when not calling unwind, i think it should fix all issues. Unfortunately, there is not much clue on this front :-(

I will continue to dig further and update. Remote gdb setup takes time but i guess that is needed.
Also, is there any quick turn around methods that would help? Like static linking of libunwind inside my library? But i am not sure how to enforce this and i always see -U in nm output for libunwind symbols even when i give absolute path of libunwind.a. This is just to see if it gives any more clues.


Also, is there any clue on why the app crashes just with linking and no
attempts made to get backtrace?

No, not from the top of my head. It could be a symbol collision as Arun mentioned.

reply via email to

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