From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: gdb still doesn't work for me
Date: 11 Apr 2001 12:07:24 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 52
Message-ID: <9b1hds$9v$1@nets3.rz.RWTH-Aachen.DE>
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> <3AD3339E DOT 2C1F2F32 AT jps DOT net> <9avce7$lab$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <3AD3DFCD DOT 9CE625B6 AT jps DOT net>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 986990844 319 137.226.32.75 (11 Apr 2001 12:07:24 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 11 Apr 2001 12:07:24 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Dennis Yelle <dennis51 AT jps DOT net> wrote:
[...]

> I compile it with 
>   gxx -gstabs -Os -Wall test.cpp -o test.exe

Tried any other option than -Os? -O1 or -O2, e.g.? -Os is a rather new
optimization option, so it's possible there are bugs in its
implementation.

> Now I do exactly this:

>   gdb test.exe
>   break main
>   run
>   n

> I expect it to 'step over' the call to car7, but instead, it
> now, with -gstabs, steps into the car7 function (or method, 
> whatever you want to call it) and shows this line:
>    8           for( i=0; i<10; i++) {

That may not be a problem in the debugger at all. Note that car7 is,
actually, not a function. It's not an ordinary method, either: it's an
*inline* method. This means that gcc is bound to expand its content at
the place it's being called, rather than call a function.

I.e. you're observing correct behaviour here, I think.

You can verify that by looking into the assembly generated by gcc (add
-save-temps to your gxx command line, and look into the file test.s
that creates, among others).

> Before, with '-g' it just gave no response of any kind for more than
> 20 seconds.

This method having been inlined, it seems, this may be due to another
shortcoming of COFF debugging information. 

So, lesson learned: to debug C++ programs, always use stabs debugging,
not COFF.

> I got it last Sunday.
> How can I tell if I got a bad one?

By looking into the debugging symbols in the assembly, for very short
programs. Andris Pavenis announced a new port of gcc-2.95.3 a few days
ago. If you got that, you should be safe from this problem.

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.