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