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. _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
