This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]