* Re: [Fwd: Gdb breakpoint bug with gcc3 on RedHat7.2]
[not found] <3C51873C.3556707B@mediaone.net>
@ 2002-03-07 10:17 ` Andrew Cagney
2002-03-07 10:21 ` Daniel Jacobowitz
0 siblings, 1 reply; 2+ messages in thread
From: Andrew Cagney @ 2002-03-07 10:17 UTC (permalink / raw)
To: Allen King; +Cc: gdb
Hello,
Can I suggest both the bug database
(http://sources.redhat.com/gdb/bugs/) and trying this on a current GDB
snapshot (http://sources.redhat.com/gdb/current). There are a number of
problems with GDB and C++ and there is a good chance that it is either
fixed or already reported.
Andrew
> 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.
>
^ permalink raw reply [flat|nested] 2+ messages in thread