Re: [Fwd: Gdb breakpoint bug with gcc3 on RedHat7.2]

[Andrew Cagney <ac131313@cygnus.com>]

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.
>