Debugging output.
- Scott
From: Scott Biersdorff
Sent: Thursday, September 04, 2014 11:14 AM
To: 'Lassi Tuura'; Arun Sharma
Cc: [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
>_Ux86_64_dwarf_find_proc_info: looking for IP=0x7f421bebb2ed
>_Ux86_64_dwarf_callback: checking , base=0x0)
>_Ux86_64_dwarf_callback: checking , base=0x7fff93cfe000)
>_Ux86_64_dwarf_callback: checking
/home/sbiersdorff/build/tools/V0.1/install/x86_64_Linux/bin/libprofileInterceptor.so,
base=0x7f421c43f000)
>_Ux86_64_dwarf_callback: checking
/usr/local/atlas/lib/libsatlas.so, base=0x7f421bc63000)
>_Ux86_64_dwarf_callback: checking
/usr/lib/x86_64-linux-gnu/libgfortran.so.3, base=0x7f421b94b000)
>_Ux86_64_dwarf_callback: checking
/lib/x86_64-linux-gnu/libc.so.6, base=0x7f421b583000)
>_Ux86_64_dwarf_callback: checking
/lib/x86_64-linux-gnu/libpthread.so.0, base=0x7f421b366000)
>_Ux86_64_dwarf_callback: checking
/lib/x86_64-linux-gnu/libdl.so.2, base=0x7f421b162000)
>_Ux86_64_dwarf_callback: checking
/usr/local/lib/libunwind.so.8, base=0x7f421af42000)
>_Ux86_64_dwarf_callback: checking
/usr/local/lib/libunwind-x86_64.so.8, base=0x7f421ad1f000)
>_Ux86_64_dwarf_callback: checking
/usr/lib/x86_64-linux-gnu/libstdc++.so.6, base=0x7f421aa1b000)
>_Ux86_64_dwarf_callback: checking
/lib/x86_64-linux-gnu/libm.so.6, base=0x7f421a717000)
>_Ux86_64_dwarf_callback: checking
/usr/lib/x86_64-linux-gnu/libquadmath.so.0, base=0x7f421a4db000)
>_Ux86_64_dwarf_callback: checking
/lib/x86_64-linux-gnu/libgcc_s.so.1, base=0x7f421a2c5000)
>_Ux86_64_dwarf_callback: checking /lib64/ld-linux-x86-64.so.2,
base=0x7f421c724000)
>_Ux86_64_dwarf_callback: checking
/lib/x86_64-linux-gnu/liblzma.so.5, base=0x7f421a0a3000)
>_Ux86_64_dwarf_find_proc_info: IP=0x7f421bebb2ed not found
>_Uelf64_string_table: strtab=0x209d8
>_Uelf64_lookup_symbol: symtab=0x8270[11]
>_Uelf64_lookup_symbol: 0x00007f421bfa8580 info=0x12
ATL_sgpmvUN_a1_x1_b0_y1
>_Uelf64_lookup_symbol: 0x00007f421bfc2f46 info=0x12
ATL_zJIK24x24x24TN0x0x0_a1_b1
>_Uelf64_lookup_symbol: 0x00007f421be382e0 info=0x12 ATL_dmmJIK
... ~8,000 symbol lookups ...
>_Uelf64_lookup_symbol: 0x00007f421bd09595 info=0x12 ztbmv_
>_Uelf64_lookup_symbol: 0x00007f421bf9baff info=0x12
ATL_sreftbsvLTU
>_Uelf64_lookup_symbol: 0x00007f421bd14546 info=0x12 cblas_stbmv
>_Uelf64_lookup_symbol: 0x00007f421c06c85c info=0x12
ATL_zrefher2U
>_Uelf64_lookup_symbol: 0x00007f421bf80d12 info=0x12
ATL_scol2blk2_aX
>_Uelf64_string_table: strtab=0x5db7dd
>_Ux86_64_step: (cursor=0x7fff93331590, ip=0x00007f421bebb2ed,
>cfa=0x00007fff93331fa8)
>get_rs_cache: acquiring lock
>_Ux86_64_dwarf_find_proc_info: looking for IP=0x7f421bebb2ed
>_Ux86_64_dwarf_callback: checking , base=0x0)
>_Ux86_64_dwarf_callback: checking , base=0x7fff93cfe000)
>_Ux86_64_dwarf_callback: checking
/home/sbiersdorff/build/tools/V0.1/install/x86_64_Linux/bin/libprofileInterceptor.so,
base=0x7f421c43f000)
>_Ux86_64_dwarf_callback: checking
/usr/local/atlas/lib/libsatlas.so, base=0x7f421bc63000)
>_Ux86_64_dwarf_callback: checking
/usr/lib/x86_64-linux-gnu/libgfortran.so.3, base=0x7f421b94b000)
>_Ux86_64_dwarf_callback: checking
/lib/x86_64-linux-gnu/libc.so.6, base=0x7f421b583000)
>_Ux86_64_dwarf_callback: checking
/lib/x86_64-linux-gnu/libpthread.so.0, base=0x7f421b366000)
>_Ux86_64_dwarf_callback: checking
/lib/x86_64-linux-gnu/libdl.so.2, base=0x7f421b162000)
>_Ux86_64_dwarf_callback: checking
/usr/local/lib/libunwind.so.8, base=0x7f421af42000)
>_Ux86_64_dwarf_callback: checking
/usr/local/lib/libunwind-x86_64.so.8, base=0x7f421ad1f000)
>_Ux86_64_dwarf_callback: checking
/usr/lib/x86_64-linux-gnu/libstdc++.so.6, base=0x7f421aa1b000)
>_Ux86_64_dwarf_callback: checking
/lib/x86_64-linux-gnu/libm.so.6, base=0x7f421a717000)
>_Ux86_64_dwarf_callback: checking
/usr/lib/x86_64-linux-gnu/libquadmath.so.0, base=0x7f421a4db000)
>_Ux86_64_dwarf_callback: checking
/lib/x86_64-linux-gnu/libgcc_s.so.1, base=0x7f421a2c5000)
>_Ux86_64_dwarf_callback: checking /lib64/ld-linux-x86-64.so.2,
base=0x7f421c724000)
>_Ux86_64_dwarf_callback: checking
/lib/x86_64-linux-gnu/liblzma.so.5, base=0x7f421a0a3000)
>_Ux86_64_dwarf_find_proc_info: IP=0x7f421bebb2ed not found
>put_rs_cache: unmasking signals/interrupts and releasing lock
>_Ux86_64_dwarf_step: returning -10
>_Ux86_64_step: dwarf_step() failed (ret=-10), trying frame-chain
>access_mem: mem[00007f421bebb2ed] -> c508427c5940a1c4
>access_mem: mem[00007f421bebb2f5] -> 792878c1c4ef58d0
>is_plt_entry: ip=0x7f421bebb2ed => 0xc508427c5940a1c4
0x792878c1c4ef58d0, ret = 0
>access_mem: mem[00007fff93331a78] -> 4620
>_Ux86_64_step: [RBP=0x7fff93331a78] = 0x4620 (cfa = 0x7fff93331fa8) -> 0x0
>_Ux86_64_step: NULL %rbp loc, returning 0
_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
