Article View: gnu.gdb.bug
Article #2807[Fwd: Gdb breakpoint bug with gcc3 on RedHat7.2]
From: Allen King
Date: Fri, 25 Jan 2002 16:26
Date: Fri, 25 Jan 2002 16:26
348 lines
13076 bytes
13076 bytes
--------------11F3BA68E22FE2F055E31798
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit
An update on the bug:
a) it also exists in gcc-3.0.3 (I compiled it yesterday from
ftp.gnu.org).
b) a breakpoint in a non-constructor method (e.g. imagine foo::goo()
below) works.
Any thoughts?
-------- Original Message --------
Subject: Gdb breakpoint bug with gcc3 on RedHat7.2
Date: Tue, 22 Jan 2002 14:59:57 -0500
From: Allen King <aking@mediaone.net>
To: bug-gdb@prep.ai.mit.edu
CC: Brian King <bak6926@usa.net>
/*:
There seems to be a bug in gdb which causes it to not stop at certain
breakpoints. It occurs with C++ sources compiled with gcc3-3.02, but
not when
gcc2-2.96 is used. All gdb versions I tried (ver 5.0rh-15 and 5.1.0.1)
had
the same problem.
I'm suspecting there may be newer versions around which have had this
(rather
basic) bug fixed, or perhaps I'm doing something wrong (..naaw).
If you can, I could use workaround/upgrade suggestions quick, as I live
in gdb
and have found progress come to a grinding halt.
The program I first encountered this in was rather large (64K lines),
but I
isolated the behavior down to the following 16-line program:
//^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (line
0)
#include <stdio.h>
class foo {
public:
foo ();
};
int main (int argc, char **argv) {
foo *myObject = new foo (); // A (line
9)
return myObject!=0; // reference it
}
foo::foo () {
printf("Why didn't the gdb breakpoint stop here?\n"); //B (line
14)
}
/*
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Info (per www.gnu.org/manual/gdb-4.17/html_chapter/gdb_18.html) is:
==================== gcc:
Both gcc3-3.0.1-3.i386.rpm (and friends) (which I did most work on) and
gcc3-3.0.2-1hn.i586.rpm (and friends) (just installed) seem to have the
same
problem. gcc2-2.96 works fine -- stops at both breakpoints.
==================== Gdb:
5.0rh-15 (from 7.2 CD) and 5.1.0.1 (made with gcc3) have the same
problem.
==================== OS:
RedHat.7.2, vmlinuz-2.4.7.
==================== CPU:
AMD-K6(tm) 3D processor, 400MHz
==================== Build and Recreate Problem:
Gdb fails to stop at the breakpoint on line 14 of the above program.
However
it is clear that line 14, a printf, does get executed -- My console log:
[me@gibson src]$ g++ --version
3.0.2
[me@gibson src]$ g++ -g main.cpp -o main
[me@gibson src]$ gdb ./main
GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) b 9
Breakpoint 1 at 0x804874d: file main.cpp, line 9.
(gdb) b 14
Breakpoint 2 at 0x80487de: file main.cpp, line 14.
(gdb) r
Starting program: /home/me/main
Breakpoint 1, main (argc=1, argv=0xbffff1d4) at main.cpp:9
9 foo *myObject = new foo (); // A
(gdb) inf b
Num Type Disp Enb Address What
1 breakpoint keep y 0x0804874d in main at main.cpp:9
breakpoint already hit 1 time
2 breakpoint keep y 0x080487de in foo::foo(int*, char const*)
at main.cpp:14
(gdb) l 14
14 printf("Why didn't the gdb breakpoint stop here?\n"); //B
(gdb) c
Continuing.
Why didn't the gdb breakpoint stop here?
Program exited with code 01.
==================== Aside
In upgrading RedHat7.2 to gcc3, I hit a knarrly problem, which I solved.
However it involved much more hackery than I would have expected, so I'm
just bringing it up as a double check: I had loaded/installed rpm's as
follows:
gcc3-3.0.1-3.i386.rpm
gcc3-c++-3.0.1-3.i386.rpm
libgcc-3.0.1-3.i386.rpm
libstdc++3-3.0.1-3.i386.rpm
libstdc++3-devel-3.0.1-3.i386.rpm
and compiles gave the error: "cannot find deque.h". File
libstdc++-v3/README
had the cryptic comment: "(A configure script may link files from
another
directory into one of these.)
The hack I did was to add about 200 symbolic links:
in /usr/include/bits, added symlinks to all files (not directories)
in the following directories:
/usr/include/g++-v3
/usr/include/g++-v3/bits
/usr/include/g++-v3/i386-redhat-linux/bits
and in /usr/include, added symlinks to all files in directory:
/usr/include/g++-v3/backward
How I determined this was by a painstaking series of compillations of a
C++
program which referenced deque.h, isolating the missing include files
and
linking where the above rpms' placed them.
Compillations after this were errorless.
--
Allen
781-248-6897 cell
781-449-3359 home
--------------11F3BA68E22FE2F055E31798
Content-Type: text/html; charset=x-user-defined
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
An update on the bug:
<p> a) it also exists in gcc-3.0.3 (I compiled it yesterday
from ftp.gnu.org).
<br> b) a breakpoint in a non-constructor method (e.g. imagine
foo::goo() below) works.
<p>Any thoughts?
<p>-------- Original Message --------
<table BORDER=0 CELLSPACING=0 CELLPADDING=0 >
<tr>
<th ALIGN=RIGHT VALIGN=BASELINE NOWRAP>Subject: </th>
<td>Gdb breakpoint bug with gcc3 on RedHat7.2</td>
</tr>
<tr>
<th ALIGN=RIGHT VALIGN=BASELINE NOWRAP>Date: </th>
<td>Tue, 22 Jan 2002 14:59:57 -0500</td>
</tr>
<tr>
<th ALIGN=RIGHT VALIGN=BASELINE NOWRAP>From: </th>
<td>Allen King <aking@mediaone.net></td>
</tr>
<tr>
<th ALIGN=RIGHT VALIGN=BASELINE NOWRAP>To: </th>
<td>bug-gdb@prep.ai.mit.edu</td>
</tr>
<tr>
<th ALIGN=RIGHT VALIGN=BASELINE NOWRAP>CC: </th>
<td>Brian King <bak6926@usa.net></td>
</tr>
</table>
<p>/*:
<p>There seems to be a bug in gdb which causes it to not stop at certain
<br>breakpoints. It occurs with C++ sources compiled with gcc3-3.02,
but not when
<br>gcc2-2.96 is used. All gdb versions I tried (ver 5.0rh-15 and
5.1.0.1) had
<br>the same problem.
<p>I'm suspecting there may be newer versions around which have had this
(rather
<br>basic) bug fixed, or perhaps I'm doing something wrong (..naaw).
<br>If you can, I could use workaround/upgrade suggestions quick, as I
live in gdb
<br>and have found progress come to a grinding halt.
<p>The program I first encountered this in was rather large (64K lines),
but I
<br>isolated the behavior down to the following 16-line program:
<p>//^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(line 0)
<br>#include <stdio.h>
<p>class foo {
<br> public:
<br> foo ();
<br>};
<p>int main (int argc, char **argv) {
<br> foo *myObject = new foo ();
// A (line 9)
<br> return myObject!=0; // reference it
<br>}
<p>foo::foo () {
<br> printf("Why didn't the gdb breakpoint stop here?\n");
//B (line 14)
<br>}
<p>/* vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
<p>Info (per www.gnu.org/manual/gdb-4.17/html_chapter/gdb_18.html) is:
<p>==================== gcc:
<br>Both gcc3-3.0.1-3.i386.rpm (and friends) (which I did most work on)
and
<br>gcc3-3.0.2-1hn.i586.rpm (and friends) (just installed) seem to have
the same
<br>problem. gcc2-2.96 works fine -- stops at both breakpoints.
<p>==================== Gdb:
<br>5.0rh-15 (from 7.2 CD) and 5.1.0.1 (made with gcc3) have the same problem.
<p>==================== OS:
<br>RedHat.7.2, vmlinuz-2.4.7.
<p>==================== CPU:
<br>AMD-K6(tm) 3D processor, 400MHz
<p>==================== Build and Recreate Problem:
<br>Gdb fails to stop at the breakpoint on line 14 of the above program.
However
<br>it is clear that line 14, a printf, does get executed -- My console
log:
<p>[me@gibson src]$ g++ --version
<br>3.0.2
<br>[me@gibson src]$ g++ -g main.cpp -o main
<br>[me@gibson src]$ gdb ./main
<br>GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
<br>Copyright 2001 Free Software Foundation, Inc.
<br>GDB is free software, covered by the GNU General Public License, and
you are
<br>welcome to change it and/or distribute copies of it under certain conditions.
<br>Type "show copying" to see the conditions.
<br>There is absolutely no warranty for GDB. Type "show warranty"
for details.
<br>This GDB was configured as "i386-redhat-linux"...
<br>(gdb) b 9
<br>Breakpoint 1 at 0x804874d: file main.cpp, line 9.
<br>(gdb) b 14
<br>Breakpoint 2 at 0x80487de: file main.cpp, line 14.
<br>(gdb) r
<br>Starting program: /home/me/main
<p>Breakpoint 1, main (argc=1, argv=0xbffff1d4) at main.cpp:9
<br>9 foo *myObject
= new foo ();
// A
<br>(gdb) inf b
<br>Num Type
Disp Enb Address What
<br>1 breakpoint keep y
0x0804874d in main at main.cpp:9
<br> breakpoint already hit 1
time
<br>2 breakpoint keep y
0x080487de in foo::foo(int*, char const*)
<br>
at main.cpp:14
<br>(gdb) l 14
<br>14 printf("Why didn't the gdb breakpoint stop here?\n");
//B
<br>(gdb) c
<br>Continuing.
<br>Why didn't the gdb breakpoint stop here?
<p>Program exited with code 01.
<br>
<p>==================== Aside
<p>In upgrading RedHat7.2 to gcc3, I hit a knarrly problem, which I solved.
<br>However it involved much more hackery than I would have expected, so
I'm
<br>just bringing it up as a double check: I had loaded/installed rpm's
as follows:
<br> gcc3-3.0.1-3.i386.rpm
<br> gcc3-c++-3.0.1-3.i386.rpm
<br> libgcc-3.0.1-3.i386.rpm
<br> libstdc++3-3.0.1-3.i386.rpm
<br> libstdc++3-devel-3.0.1-3.i386.rpm
<p>and compiles gave the error: "cannot find deque.h". File libstdc++-v3/README
<br>had the cryptic comment: "(A configure script may link files from another
<br>directory into one of these.)
<p>The hack I did was to add about 200 symbolic links:
<p> in /usr/include/bits, added symlinks to all files
(not directories)
<br>in the following directories:
<br> /usr/include/g++-v3
<br> /usr/include/g++-v3/bits
<br> /usr/include/g++-v3/i386-redhat-linux/bits
<p> and in /usr/include, added symlinks to all files
in directory:
<br> /usr/include/g++-v3/backward
<p>How I determined this was by a painstaking series of compillations of
a C++
<br>program which referenced deque.h, isolating the missing include files
and
<br>linking where the above rpms' placed them.
<p>Compillations after this were errorless.
<br>
<pre>--
Allen
781-248-6897 cell
781-449-3359 home</pre>
</html>
--------------11F3BA68E22FE2F055E31798--
Technical Details
Message-ID:
<3C51873C.3556707B@mediaone.net>Path:
arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!newsfeed.online.be!zur.uu.net!ash.uu.net!spool0901.news.uu.net!wendy-fate.uu.net!bug-gdbShow Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f5053,1ef30ed787db11bf,start X-Google-Attributes: gidf5053,public X-Google-ArrivalTime: 2002-01-25 08:12:29 PST x-uunet-gateway: mr0.ash.ops.us.uu.net from bug-gdb to gnu.gdb.bug; Fri, 25 Jan 2002 16:12:27 GMT Sender: me@chmls20.mediaone.net Message-ID: <3C51873C.3556707B@mediaone.net> Date: Fri, 25 Jan 2002 11:26:37 -0500 From: aking@mediaone.net (Allen King) X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.7-50 i586) X-Accept-Language: en MIME-Version: 1.0 Subject: [Fwd: Gdb breakpoint bug with gcc3 on RedHat7.2] Content-Type: multipart/alternative; boundary="------------11F3BA68E22FE2F055E31798" Approved: bug-gdb-request@mail.gnu.org Newsgroups: gnu.gdb.bug Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!newsfeed.online.be!zur.uu.net!ash.uu.net!spool0901.news.uu.net!wendy-fate.uu.net!bug-gdb Lines: 349