From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sources.redhat.com
Subject: "next" single-steps all the way
Date: Wed, 11 Apr 2001 05:16:00 -0000
Message-id: <200104111215.IAA15143@delorie.com>
X-SW-Source: 2001-04/msg00083.html

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