>
>
> 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.
>
>
>
_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel

Reply via email to