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.
No, not from the top of my head. It could be a symbol collision as Arun mentioned.
Also, is there any clue on why the app crashes just with linking and no
attempts made to get backtrace?