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

[Andrew Cagney <cagney@gnu.org>]

>>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
> 
> 
> sounds ok; i'm curious about what are the other trampoline cases that we
> need to deal with. i found another case on hppa where what needs to
> happen doesn't really match what infrun.c is doing (i'll describe it
> below), but it'll be good if somehow we can handle these in a sort of
> standard way so that h_i_e is actually understandable :)
> 
> the other problem i've seen is when stepping into a shared library call
> -- again, this goes through a stub. gdb steps into the stub, but before
> it has a chance to skip over the stub, it hits this (since the stub has
> no corresponding symbol):

That case should be handled by the same skip-trampoline logic (it is 
just another trampoline).

>   if (step_over_calls == STEP_OVER_UNDEBUGGABLE
>       && ecs->stop_func_name == NULL)
>     {
>       /* The inferior just stepped into, or returned to, an
>          undebuggable function (where there is no symbol, not even a
>          minimal symbol, corresponding to the address where the
>          inferior stopped).  Since we want to skip this kind of code,
>          we keep going until the inferior returns from this
>          function.  */
> [...]
>           /* Set a breakpoint at callee's return address (the address
>              at which the caller will resume).  */
>           insert_step_resume_breakpoint (get_prev_frame (get_current_frame ()),
>                                          ecs);
>           keep_going (ecs);
>           return;
>     }
> 
> if i move this block after the next block (that checks for stub frames
> and does SKIP_TRAMPOLINE_CODE () processing) then it works...
> 
> I'm still trying to understand why the checks in h_i_e happen in the
> current order.... so i don't know whether this is a problem with h_i_e
> or somewhere else...

The rationale (if we think it can be called that :-) is lost in the 
depths of time.   Perhaps some unwinders barfed when presented with a 
function with no function name so it was thought that doing the check 
first was prudent?

Anyway, can the IN_SOLIB_RETURN_TRAMPOLINE be moved up as well (with an 
additional ecs->stop_func_name != NULL check?

Andrew