Date: Thu, 24 Feb 2000 16:28:03 +0200 (WET) From: Andris Pavenis To: Eli Zaretskii cc: djgpp-workers AT delorie DOT com Subject: Re: Debugging difficulties with GCC 2.95.2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: dj-admin AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Thu, 24 Feb 2000, Eli Zaretskii wrote: > Did someone notice some debugging problems with GCC 2.95.2? For example, > the short test program below, when compiled with GCC 2.95.2, cannot be > stepped on the source level. That is, the following sequence: > > gdb fpfunc > b main > r > s > > causes the program to run to completion after the `s' command, instead of > stepping into dfunc(). This doesn't happen with GCC 2.7.2.1. I tried > both -g and -gstabs with 2.95.2, it behaves the same with both. > > FWIW, the command to compile was "gcc -Wall -O -g -o fpfunc fpfunc.c". > > This might seem like a toy problem, but I have seen similar problems in > much larger programs, like Emacs: some breakpoints simply don't break > even though I *know* the program passed those points. Come to think of > it, all the cases I saw were when the breakpoint was set on the entry to > a function. Again, when compiled with GCC 2.7.2.1, the breakpoints > behave like expected. > > Any ideas? > Seems that there are similar problems. However for this example using -gstabs+ instead of -g would help. I sometimes met similar problems with my own code which heavily uses STL (most tests doen under Linux) Andris > > #include > > double dfunc (double a) > { > return a * sqrt (a); > } > > float ffunc (float b) > { > return b * (float)dfunc (b); > } > > int main (int argc, char *argv[]) > { > return (dfunc (argc) > 2 ? 0 : 1); > } > >