|
From: | Scott Biersdorff |
Subject: | Re: [Libunwind-devel] Unwinding from optimzied shared library on linux |
Date: | Tue, 16 Sep 2014 00:19:33 +0000 |
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
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:
address@hidden [mailto:address@hidden]
On Behalf Of Lassi Tuura 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 <address@hidden> wrote: On Thu, Sep 4, 2014 at 5:42 AM, Scott Biersdorff <address@hidden> wrote: I noticed that addresses in gdb stack trace and libunwind weren't the |
[Prev in Thread] | Current Thread | [Next in Thread] |