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

[Allen King]

So now it's nearly 9 months later, and this bug still exists! Now I'm using

RedHat 8.0

GNU gdb Red Hat Linux (5.2.1-4)
running gdb from xterm, emacs, or ddd gives equal (poor) results.

gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
also the same with gcc 3.0.2

Is this any way to run a railroad?  I did get it down to a 16 line
program, but I'd be happy to work with you on it farthur.

        Allen King

Good debuggers make for healty software -- long live GNU!

-------- Original Message --------

Subject:	Gdb breakpoint bug with gcc3 on RedHat7.2
Date:	Tue, 22 Jan 2002 14:59:57 -0500
From:	Allen King <address@hidden>
To:	address@hidden
CC:	Brian King <address@hidden>

/*:

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:

address@hidden src]$ g++ --version
3.0.2
address@hidden src]$ g++ -g main.cpp -o main
address@hidden 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