* gdbarch_skip_solib_resolver question
@ 2012-01-10 20:09 Michael Eager
2012-01-11 8:44 ` Mark Kettenis
0 siblings, 1 reply; 6+ messages in thread
From: Michael Eager @ 2012-01-10 20:09 UTC (permalink / raw)
To: gdb
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?
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdbarch_skip_solib_resolver question
2012-01-10 20:09 gdbarch_skip_solib_resolver question Michael Eager
@ 2012-01-11 8:44 ` Mark Kettenis
2012-01-11 16:24 ` Michael Eager
2012-01-11 17:06 ` Michael Eager
0 siblings, 2 replies; 6+ messages in thread
From: Mark Kettenis @ 2012-01-11 8:44 UTC (permalink / raw)
To: Michael Eager; +Cc: gdb
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdbarch_skip_solib_resolver question
2012-01-11 8:44 ` Mark Kettenis
@ 2012-01-11 16:24 ` Michael Eager
2012-01-11 17:06 ` Michael Eager
1 sibling, 0 replies; 6+ messages in thread
From: Michael Eager @ 2012-01-11 16:24 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb
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.
OK, that matches what I see. Except that gdb always steps over the
call and never stops in the target function.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdbarch_skip_solib_resolver question
2012-01-11 8:44 ` Mark Kettenis
2012-01-11 16:24 ` Michael Eager
@ 2012-01-11 17:06 ` Michael Eager
2012-01-11 17:13 ` Pedro Alves
1 sibling, 1 reply; 6+ messages in thread
From: Michael Eager @ 2012-01-11 17:06 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: gdbarch_skip_solib_resolver question
2012-01-11 17:06 ` Michael Eager
@ 2012-01-11 17:13 ` Pedro Alves
2012-01-11 17:38 ` Michael Eager
0 siblings, 1 reply; 6+ messages in thread
From: Pedro Alves @ 2012-01-11 17:13 UTC (permalink / raw)
To: Michael Eager; +Cc: Mark Kettenis, gdb
On 01/11/2012 05:05 PM, Michael Eager wrote:
> 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.
That's not the only time in_solib_dynsym_resolve_code returns true,
see svr4_in_dynsym_resolve_code. It returns true as well when the
PC is within the interpreter / dynamic linker's text.
--
Pedro Alves
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdbarch_skip_solib_resolver question
2012-01-11 17:13 ` Pedro Alves
@ 2012-01-11 17:38 ` Michael Eager
0 siblings, 0 replies; 6+ messages in thread
From: Michael Eager @ 2012-01-11 17:38 UTC (permalink / raw)
To: Pedro Alves; +Cc: Mark Kettenis, gdb
On 01/11/2012 09:13 AM, Pedro Alves wrote:
> On 01/11/2012 05:05 PM, Michael Eager wrote:
>
>> 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.
>
> That's not the only time in_solib_dynsym_resolve_code returns true,
> see svr4_in_dynsym_resolve_code. It returns true as well when the
> PC is within the interpreter / dynamic linker's text.
Yes, I just noticed this.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-11 17:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-10 20:09 gdbarch_skip_solib_resolver question Michael Eager
2012-01-11 8:44 ` Mark Kettenis
2012-01-11 16:24 ` Michael Eager
2012-01-11 17:06 ` Michael Eager
2012-01-11 17:13 ` Pedro Alves
2012-01-11 17:38 ` Michael Eager
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox