From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26839 invoked by alias); 7 Mar 2002 18:17:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26680 invoked from network); 7 Mar 2002 18:17:20 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 7 Mar 2002 18:17:20 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6FE093E74; Thu, 7 Mar 2002 13:17:18 -0500 (EST) Message-ID: <3C87AEAE.8090007@cygnus.com> Date: Thu, 07 Mar 2002 10:17:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: Allen King Cc: gdb@sources.redhat.com Subject: Re: [Fwd: Gdb breakpoint bug with gcc3 on RedHat7.2] References: <3C51873C.3556707B@mediaone.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00052.txt.bz2 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 > To: bug-gdb@prep.ai.mit.edu > CC: Brian King > > /*: > > 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 > > 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. >