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

[Andrew Cagney <cagney@gnu.org>]

>>>  > +  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? 
> 
> 
> Hmmm, good question...
> 
> Although it does fix regression #2, it is not the only reason why we
> added this test. It was also based on logic (see "After ... here is
> what we found", in my previous message).
> 
> I should admit that in the case at hand (regression #2), the unwinder
> is having a hard time unwinding out of this code, and causes the
> frame ID check to fail. I don't remember seeing several levels of
> function call.
> 
> However, I still thought that this test was necessary because we could
> just as well have reached this trampoline one or more levels of function
> call down, just as we end up stepping into undebuggable code in
> regression #1.

I'd not noticed this issue.  Hmm, if GDB's single stepping then the 
second test should cover this case.  It's when GDB is free running that 
we might find ourselves stopped IN_SOLIB_CALL_TRAMPOLINE.  If it is the 
latter case then I'm not sure that silently single stepping away from 
where the program stopped is being helpful.

Can you try the testsuite without that check?  If the results are ok 
then (with other changes) commit it.  If its not we need to re-think 
whats happening :-(  Yes, this will mean it goes into 6.1.

Andrew