Re: [Libunwind-devel] [PATCH 6/8] Recognise and unwind through PLT.

[Lassi Tuura]

Hi,

> Actually, compiling with -fasynchronous-unwind-tables + CFI annotations in 
> getcontext.S fixed only one regression (test-async-sig). The other regression 
> (run-ptrace-mapper) is still there. It's a bit harder to debug (gdb doesn't 
> work well). That's the only thing holding your first patch set back.
> 
> Good run:
> 
>  >_Ux86_64_init_remote: (cursor=0x7fff7a5c1800)
>  >_Ux86_64_dwarf_search_unwind_table: e->fde_offset = c3a4, segbase = 
> 2ae3d541cdfc, debug_frame_base = 0, fde_addr = 2ae3d54291a0
>  >_Ux86_64_step: (cursor=0x7fff7a5c1800, ip=0x00002ae3d53474ae, 
> cfa=0x00007fffd5e70870)
>  >_Ux86_64_dwarf_search_unwind_table: e->fde_offset = c3a4, segbase = 
> 2ae3d541cdfc, debug_frame_base = 0, fde_addr = 2ae3d54291a0
>  >_Ux86_64_dwarf_search_unwind_table: e->fde_offset = 40, segbase = 400ab0, 
> debug_frame_base = 0, fde_addr = 400af0
>  >_Ux86_64_step: (cursor=0x7fff7a5c1800, ip=0x0000000000400918, 
> cfa=0x00007fffd5e708a0)
>  >_Ux86_64_dwarf_search_unwind_table: e->fde_offset = 612c, segbase = 
> 2ae3d541cdfc, debug_frame_base = 0, fde_addr = 2ae3d5422f28
>  >_Ux86_64_step: (cursor=0x7fff7a5c1800, ip=0x00002ae3d52fb5a6, 
> cfa=0x00007fffd5e708e0)
>  >_Ux86_64_dwarf_search_unwind_table: IP 400768 inside range 400000-400b6c, 
> but no explicit unwind info found
>  >_Ux86_64_step: (cursor=0x7fff7a5c1800, ip=0x0000000000400769, 
> cfa=0x00007fffd5e70990)
>  >_Ux86_64_dwarf_search_unwind_table: IP 400768 inside range 400000-400b6c, 
> but no explicit unwind info found
> 
> Bad run:
> 
>  >_Ux86_64_init_remote: (cursor=0x7fff7a5c1800)
>  >_Ux86_64_dwarf_search_unwind_table: e->fde_offset = c3a4, segbase = 
> 2ae3d541cdfc, debug_frame_base = 0, fde_addr = 2ae3d54291a0
>  >_Ux86_64_step: (cursor=0x7fff7a5c1800, ip=0x00002ae3d53474b2, 
> cfa=0x00007fffd5e70898)
>  >_Ux86_64_dwarf_search_unwind_table: e->fde_offset = c3a4, segbase = 
> 2ae3d541cdfc, debug_frame_base = 0, fde_addr = 2ae3d54291a0
>  >_Ux86_64_step: (cursor=0x7fff7a5c1800, ip=0x00007fffd5e709a0, 
> cfa=0x00007fffd5e708c8)
>  >_Ux86_64_step: [RBP=0x7fffd5e708a8] = 0x100400950 (cfa = 0x7fffd5e708c8)
>  >_Ux86_64_step: Frame Chain [RIP=0x100400958] = 0xffffffffffffffff
> FAILURE: unw_step() returned -8 for ip=ffffffffffffffff (start 
> ip=2ae3d53474b2)
> unwind failed with ret=-8

What's at ip 0x2ae3d53474b2? It clearly goes amok after that, 0x7fffd5e709a0 
seems like stack not code address. Since it comes from real unwind info, that 
seems unlikely thing to get wrong. One guess is missing unwind info for an 
epilogue.

I'd be interested in "objdump -d libabc.so | grep -B20 474b2:" for whatever 
library that came from, and if necessary, "readelf -WwF" output for the 
corresponding FDE.

Note that the above aren't identical unwinds, they start at a different address 
(...ae vs. ...b2). I'll try to debug this tomorrow, but it didn't get the test 
case to fail in my earlier trials.

Regards,
Lassi

PS. -fasynchronous-unwind-tables is supposedly the default on x86_64. At least 
in my tests it didn't make the slightest difference in the unwind info 
generated. Building with GCC 4.5 does help big time, but clearly can't fix your 
libc, libm, libdl or ld-linux.