This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdbarch_skip_solib_resolver question
On 01/11/2012 12:43 AM, Mark Kettenis wrote:
I noticed that gdbarch_skip_solib_resolver() invokes
glibc_skip_solib_resolver() on x86, mips, and sh to identify
that gdb is stepping into _dl_runtime_resolve.
On PowerPC, gdbarch_skip_solib_resolver() always returns a zero.
I don't see any problem with gdb stopping in _dl_runtime_resolve
or not stepping over the routine.
So, what does this mean? Is calling glibc_skip_solib_resolver()
optional? Or is the handle_inferior_event() code so convoluted
or intelligent that it works even when pieces are missing?
If I remember correctly, gdbarch_skip_solib_resolver() is just an
optimization. If it returns an address where GDB can set a breakpoint
that gets hit upon return from the dynamic linker. If
gdbarch_skip_solib_resolver() returns zero GDB just single-steps through
the dynamic linker, which works, but is a bit slower.
This is glibc_skip_solib_resolver():
struct minimal_symbol *resolver
= lookup_minimal_symbol_and_objfile ("_dl_runtime_resolve", &objfile);
if (resolver)
{
/* The dynamic linker began using this name in early 2005. */
struct minimal_symbol *fixup
= lookup_minimal_symbol ("_dl_fixup", NULL, objfile);
...
if (fixup && SYMBOL_VALUE_ADDRESS (fixup) == pc)
return frame_unwind_caller_pc (get_current_frame ());
}
return 0;
Unless I'm reading the code wrong, I don't think this can ever return
non-zero. This is called from handle_inferior_event (infrun.c:4754)
when in_solib_dynsym_resolve_code() is true. This means that the
pc points to the start of a PLT stub. The test to see if it is
at _dl_fixup will always fail.
It looks to me that this should return the address of _dl_fixup
and eliminate the frame_unwind.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077