gdbarch_skip_solib_resolver question

Michael Eager
Wed Jan 11 17:06:00 GMT 2012

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
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

More information about the Gdb mailing list