Re: [patch/rfc] How to handle stepping into an unresolved plt entry?

[Andrew Cagney <cagney@gnu.org>]

> On hppa, I noticed that when I do a "step" over an indirect function
> call, gdb does not stop inside the called function.  I've traced the
> problem down to the following:
> 
> An indirect function call on hppa goes through a stub ($$dyncall).
> $$dyncall loads a PLABEL from the PLT and jumps to it. In the case that
> the PLT is not yet resolved, we need to do the normal PLT fixup () in 
> the loader before calling the function.
> 
> What seems to be happening now is that when a "step" happens at the
> indirect function call, we step into the $$dyncall stub, and in
> infrun.c, we do a SKIP_TRAMPOLINE_CODE. This resolves into a pc that
> points at the fixup routine. Next, in handle_inferior_event (), we try
> to lookup the file/line information for this target pc; it's not found,
> and so gdb just goes ahead and insert a breakpoint at the return address
> of the stub (which is in the caller) and then calls keep_going ().
> If we do a step on a second invocation of the indirect function call, it
> works correctly; SKIP_TRAMPOLINE_CODE resolves to an address that points
> to the target function, so the file/line lookup works and we insert a
> breakpoint in the right place.

Hmm, should gdb put a greater reliance on SKIP_TRAMPOLINE_CODE. 
Something like a new separate clause:

   if (we've stepped into a function
       && we're not stopping in this sort of code
       && skip trampoline returns something)
     run to skip trampoline breakpoint, possibly doing a step into function


> What is actually supposed to happen in this case? The documentation says:
> @findex SKIP_TRAMPOLINE_CODE

I think these should be generic attributes of the frame, as you note, 
there are already too many special cases.

Andrew

> If the target machine has trampoline code that sits between callers and
> the functions being called, then define this macro to return a new PC
> that is at the start of the real function.
> 
> But how do you do this if your target address is not yet resolved? The
> attached patch gives a workaround for this problem (also needs a small
> fix to the target code), but it seems a bit clumsy to me.... it's not
> like handle_inferior_event () needs any more special cases... :-(
> 
> Comments? Suggestions?