Message-ID:	<XFMail.000303015315.markus.oberhumer@jk.uni-linz.ac.at>
X-Mailer:	XFMail 1.3 [p0] on Linux
X-Priority:	3 (Normal)
MIME-Version:	1.0
In-Reply-To:	<Pine.SUN.3.91.1000224135720.14304I-100000@is>
X-no-Archive:	yes
Return-Read-To:	markus DOT oberhumer AT jk DOT uni-linz DOT ac DOT at
Return-Received-To:	markus DOT oberhumer AT jk DOT uni-linz DOT ac DOT at
Date:	Fri, 03 Mar 2000 01:53:15 +0100 (CET)
From:	"Markus F.X.J. Oberhumer" <markus DOT oberhumer AT jk DOT uni-linz DOT ac DOT at>
To:	djgpp-workers AT delorie DOT com
Subject:	RE: Debugging difficulties with GCC 2.95.2
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id TAA31773
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

JFYI, the same happened to me some days ago when upgrading
to the latest gcc & binutils versions under Debian/Linux.

When using `-g' or `-gstabs+3' breakpoints were pointing to
completely random code. I didn't bother to look for the exact
problem once I found out that `-gstabs' was still working,
but I highly suspect a gcc problem.

Markus

On 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?
> 
> 
>#include <math.h>
> 
> 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);
> }
> 

----   Markus F.X.J. Oberhumer  @  http://oberhumer.tsx.org   ----
----     5E CB 5C 85 DE AF 9E BF  E9 DA 7E 6A 39 F8 CC 67     ----

                      3 WARPS TO URANUS

- Raw text -