This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: "next" single-steps all the way
- To: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Subject: Re: "next" single-steps all the way
- From: Fernando Nasser <fnasser at redhat dot com>
- Date: Wed, 11 Apr 2001 08:53:22 -0400
- CC: gdb at sources dot redhat dot com
- Organization: Red Hat Canada
- References: <200104111215.IAA15143@delorie.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