Hi, Any suggestions on how to pin down the exact cause of this unwind failure? So far compiling with ‘--fasynchronous-unwind-tables’ has not improved libunwind’s ability to get farther up the stack.
Thanks, - Scott From: Scott Biersdorff Sent: Thursday, September 04, 2014 11:14 AM To: 'Lassi Tuura'; Arun Sharma Cc: [email protected]<mailto:[email protected]>; Juul VanderSpek Subject: RE: [Libunwind-devel] Unwinding from optimzied shared library on linux Hi, Yes, this is from ATLAS auto-tuning library. I checked and the library is not compiled with -fasynchronous-unwind-tables flag so that could very well be the issue because the unwinding is happening from a signal handler. If it provides any more information I’ve attached more debugging information. Readelf does show an FDE entry but the information is very minimal: 000163c0 0000000000000014 00000000000163c4 FDE cie=00000000 pc=0000000000253e00..0000000000253eb1 LOC CFA ra 0000000000253e00 rsp+8 c-8 0000000000253e04 rsp+48 c-8 0000000000253eb0 rsp+8 c-8 Thanks, Scott From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Lassi Tuura Sent: Thursday, September 04, 2014 1:39 AM To: Arun Sharma Cc: Scott Biersdorff; [email protected]<mailto:[email protected]>; Juul VanderSpek Subject: Re: [Libunwind-devel] Unwinding from optimzied shared library on linux Is this part of ATLAS fortran or some of the auto-tuned platform specific code? My default would be to check that you actually have unwind tables; I don't recall if gfortran produces them by default. In addition to Arun's suggestion, you can check that "readelf -WwF /usr/local/atlas/lib/libsatlas.so" shows a FDE entry, stack movement and register location information for the PC ranges of each of those functions. "nm -D -n /usr/local/atlas/lib/libsatlas.so" will tell you the function addresses to compare with. As Arun suggested, using more verbose libunwind debugging will help too. On Thu, Sep 4, 2014 at 3:59 AM, Arun Sharma <[email protected]<mailto:[email protected]>> wrote: On Thu, Sep 4, 2014 at 5:42 AM, Scott Biersdorff <[email protected]<mailto:[email protected]>> wrote: > Hi, > > > I am attempting to unwind from an optimized shared (non-stripped) library > compiled with debugging information. However I cannot unwind pass the second > entry on the call stack. Ideally I would like to unwind all the way back to > main and I understand libunwind has techniques it uses when and if the frame > pointers/dwarf information is unavailable and I want to make sure that I’m > using libunwind in such a way that gives it is the best possibility to use > these techniques. Here are some details: > I noticed that addresses in gdb stack trace and libunwind weren't the same. Perhaps turn off address space randomization in the kernel to compare the two unwinders? Other things I'd check: * Does the binary have .eh_frame section intact? * Any hand written asm function with missing unwind info? * Are async signals involved? If so, you'll need to compile with --fasynchronous-unwind-tables fasynchronous-unwind-tables Also, at higher UNWIND_DEBUG_LEVELs you'll see more information about the point where libunwind switched from DWARF based unwinding to frame pointer based unwinding due to lack of debug info. -Arun _______________________________________________ Libunwind-devel mailing list [email protected]<mailto:[email protected]> https://lists.nongnu.org/mailman/listinfo/libunwind-devel
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
