Re: [Libunwind-devel] Unwinding from optimzied shared library on linux

[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
Sent: Thursday, September 04, 2014 1:39 AM
To: Arun Sharma
Cc: Scott Biersdorff; address@hidden; 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 <address@hidden> wrote:

On Thu, Sep 4, 2014 at 5:42 AM, Scott Biersdorff <address@hidden> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/libunwind-devel