> application compiled with default gcc options.
Those are ARM specific unwind mechanisms. On x64, we just use dwarf +
.eh_frame. Ken seems to have a wiki on some of these topics:
https://wiki.linaro.org/KenWerner/Sandbox/libunwind
Thanks. Yes, i looked at that and then only got to this stage.
However, when i checked it again, in the presentation slides Ken compiles his app with -funwind-tables option.
I had a unit test program which still uses the C++ framework used by main App. I quickly changed it to add this option for all the libraries it builds.
It works fine and even unwinds stack properly :-). This unit test app was crashing before even when i just link with -lunwind. Is this something specific to "-funwind-tables" option? Do all app needs to be compiled with this option? or may be out of the 4 options tried by libunwind (arm) only this option is stable?
I will give a try with my main app tomorrow and see. I did not notice any huge difference in size of segments because of this option but it is still worth a try i guess. Will update tomorrow.
> Still, I am not sure how those 3 symbols alone causes crash even when not
> called. Those names doesn't look like one colliding with global namespace?
Even when you don't invoke any APIs there may be some static
initializers in the library that executed. Or it could be some random
limit on code or data segment that was exceeded by linking the
library. The best option is to gdb + symbols working for your
environment. Hopefully one of the ARM experts reading the list will
help you out.
I hope and pray for it. I am so close and don't want to give up on this :-)
Thanks
-Arun