Message-ID: <3AD3339E.2C1F2F32@jps.net>
From: Dennis Yelle <dennis51 AT jps DOT net>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: gdb still doesn't work for me
References: <3AD0B992 DOT 44D0D3C3 AT jps DOT net> <4634-Sun08Apr2001234906+0300-eliz AT is DOT elta DOT co DOT il> <3AD10B71 DOT 9019CC9 AT jps DOT net> <3AD1E414 DOT 8D811D08 AT jps DOT net> <9auqog$6ah$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 97
Date: Tue, 10 Apr 2001 09:23:58 -0700
NNTP-Posting-Host: 216.119.25.37
X-Complaints-To: abuse AT onemain DOT com
X-Trace: nntp3.onemain.com 986919532 216.119.25.37 (Tue, 10 Apr 2001 12:18:52 EDT)
NNTP-Posting-Date: Tue, 10 Apr 2001 12:18:52 EDT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Hans-Bernhard Broeker wrote:
> 
> Dennis Yelle <dennis51 AT jps DOT net> wrote:
> [...]
> 
> > My programs usually take at least 20 times as long to run when I run
> > them under gdb rather than directly from the command line.  Is this
> > normal behavior for gdb?
> 
> Definitely not.
> 
> I have one suspicion regarding a possible reason: you're not using
> -gstabs, and you're compiling C++ code. That's not a very good
> combination, generally. The difference in format of debugging
> information might cause GDB to be very slow at finding the source line
> corresponding to a particular program counter register value.
> 
> > What is going on here?  Does gdb ever work right?
> 
> You're overreacting a bit, I think. Just because it seems to be a bit
> slower than you expect doesn't mean it's not working correctly.
> 
> To give it a fair chance, you also should not be testing the program
> in single-step mode. Try
> 
>         gdb test.exe
>         gdb > run
> 
> or
> 
>         gdb test.exe
>         gdb > b main
>         gdb > run
>         gdb > continue
> 
> for a change.

Thanks for the suggestion, -gstabs definitely changes
the behavior of gdb.  It still does not work the
way I want it to, or the way I expect it to.

My understanding is that the command 'n' is
'step over'.  That is, if the next line to be
executed is line 20, and line 20 calls a function,
or method, then the 'n' command would
be equivalent to setting a breakpoint on line 21 and
running the program until line 21 is reached.

If this is not what the 'n' command does, then,
Is there a single command that does this?

I have never used a debugger before that did not have
a single simple command for this function.  I thought
that the gdb command for this was 'n', but it sure
does not seem to work that way.

What I have been attempting to do is simply 'step over'
the static method call in main, but the fact that this
takes just about forever suggests to me that gdb is actually
single stepping thru the method instead of stepping over it.
There simply must be a way to do what I want to do,
every other debugger I have ever used in the last 25 years
has been able to do this.

Here is the source code again, just so
everyone can see just how simple this program is:
----------------------------------------
int count;
int i, k;

class Paths {
public:
  static void car7()
  {
    for( i=0; i<10; i++) {
      for( k=0; k<1000000; k++) {
        if ( (i | k) == 127)
          ++count;
      }
    }
  }
};

int main()
{
  count = 0;
  Paths::car7();
  count += 2;
  return count;
}
------------------------------------------

Dennis Yelle
-- 
I am a computer programmer and I am looking for a job.
There is a link to my resume here:  
http://table.jps.net/~vert/