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