Re: [RFA] use frame IDs to detect function calls while stepping

[Elena Zannoni <ezannoni@redhat.com>]

Joel Brobecker writes:
 > [aghaaaaa .... With the patch this time, with my thanks to Elena and Daniel]
 > 
 > Hello,
 > 
 > This is a followup on the discussion that took place in the following
 > thread:
 > 
 >     [RFA] OSF/1 - "next" over prologueless function call
 >     http://sources.redhat.com/ml/gdb-patches/2003-12/msg00037.html
 > 
 > During the discussion, it appeared that it was better to rely on
 > frame IDs to detect cases when we stepped inside a function rather
 > than further adjusting the test that checks whether we landed at
 > the begining of a function or not.
 > 
 > After a bit of testing on various platforms, I found that only relying
 > on a test that checks the ID of frame #1 against the step_frame_id was
 > not sufficient, unfortunately. The sparc-solaris testing revealed 2
 > regressions.
 > 
 > After careful analysis of the regressions and a bit of dicussion
 > with Andrew, here is what we found:
 > 
 >   1. We sometimes step levels of function calls down from the point
 >      where we started stepping. This is to get past the dynsym
 >      resolve code. So once we get more than one level deep, the
 >      frame ID test can no longer work.
 >      
 >      That was regression #1.
 > 
 >   2. We have a testcase where we try to "next" our way out of a function
 >      for which we have no line number information. The expected output
 >      was to run until the end of the program. But instead we stopped
 >      before.
 > 
 >      It turned out that we were landing inside a shared library
 >      trampoline after having left the function we were in, so again
 >      the frame ID check didn't kick in. We didn't know what to do,
 >      simply stopped there.
 > 
 >      That was regression #2.
 > 
 > Given the current implementation, and the analysis of the regressions,
 > we determined that the logic should be something like this:
 > 
 >   . If we landed in undebuggable code (identified by lack of symbol
 >     name), and we're stepping over this kind of code, then:
 >     
 >         Run our way out of the function.
 >   

Could this kind of logic be handled inside handle_step_into_function
(which already checks for UNDEBUGGABLE)?  I.e. is this case caught by
the complex condition in the old frame case which makes you call
handle_step_into_function? For the new frame case, this is regression
#1,  did you have this bug/regression with the old frame code?


 >   . If we are in a shlib call trampoline, then:
 > 
 >         Likewise.
 >         (This test was already part of the previous check, BTW)
 > 
 >   . If we are in a function called from the function where we started
 >     stepping, as identified by frame ID unwind, then:
 > 
 >         Likewise.
 > 
 > I tried it and no longer had any regression.
 > 

I think the explanations above should go in the function as comments.


 > +  else
 > +    {
 > +      if (IN_SOLIB_CALL_TRAMPOLINE (stop_pc, ecs->stop_func_name))
 > +        {
 > +          /* We landed in a shared library call trampoline, so it
 > +             is a subroutine call.  */
 > +          handle_step_into_function (ecs);
 > +          return;
 > +        }


I am not sure I understand why the case above is not covered by the
test below.  Is this to fix regression #1? I.e multiple frames? 

 > +
 > +      if (frame_id_eq (get_frame_id (get_prev_frame (get_current_frame ())),
 > +                       step_frame_id))
 > +        {
 > +          /* It's a subroutine call.  */
 > +          handle_step_into_function (ecs);
 > +          return;
 > +        }
 > +
 >      }
 >  
 >    /* We've wandered out of the step range.  */