Re: "next" single-steps all the way

[Fernando Nasser <fnasser@redhat.com>]

Eli,

The core of the problem is that GDB is not recognizing car7() as a
function (method).  Maybe it has been inlined? 


So, for all practical purposes, this would be the same as if you use
"step" in a line like the following:

     for (i=0; i < NNNNNN; i++) ;

If NNNNNN is large, "step" will take a very, very long time :-(



To prevent this cases, we could add a new GDB setting: max_single_steps
that would cause a confirmation message to be asked to the user (after
printing where it is currently).


Anyway, your problem seem to be related to prologue-less functions.  The
in_prologue() test is not firing.





Eli Zaretskii wrote:
> 
> Here's a simple C++ program, call it car.cc:
> 
>     int count;
>     int i, k;
> 
>     class Paths {
>     public:
>       static void car7()
>       {
>       for( i=0; i<10; i++) {
>         for( k=0; k<1000; k++) {
>             if ( (i | k) == 127)
>                   ++count;
>                     }
>                     }
>       }
>     };
> 
>     int main()
>     {
>       count = 0;
>       Paths::car7();
>       count += 2;
>       return count;
>     }
> 
> I compile it like this:
> 
>   g++ -Wall -Os -g -o car car.cc
> 
> Then debug it like this:
> 
>   gdb car
>   (gdb) b 18
>   (gdb) r
>   (gdb) n
> 
> That "next" command takes forever to execute, because it seems to
> single-step the whole body of Paths::car7, instead of stepping over
> it.
> 
> It looks like the reason is that GCC inlines the entire body of
> Paths::car7, and that somehow confuses the logic of "next".  It
> normally makes a single step into car7, then puts a breakpoint on the
> return address of car7 and then resumes the debuggee.  However, in
> this case, the body of Paths::car7 has no frame and no return address,
> so GDB continues single stepping all the way.
> 
> This happens with DJGPP, so it could be something specific to the
> DJGPP port of GDB or the debug info emitted by the DJGPP port of GCC.
> I did try both with -gcoff and -gstabs+, just to be sure, and it
> didn't seem to help much.
> 
> Do others see this on other platforms?
> 
> Is my analysis of the problem correct?  If so, can this be corrected
> somehow?  I think at the very least GDB should announce that it is
> single stepping, so that the user expects slow execution.  (The
> original real-life version of the above code had 4 nested loops, so
> the total loop count was much greater than 10000, and the program
> would _really_ run forever.)
> 
> TIA

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9