Re: gdb 5.3 issues with g++ 3.2 on RedHat 7.3 & Solaris 9.

["Joshua D. Marantz" <josh at carbondesignsystems dot com>]

I'm sorry it took so long to respond to this.  I've now got clean
builds of gcc 3.2.1 with the latest binutils, and gdb 5.3 using gcc
3.2.1.  I can reproduce the problem easily on a tiny example.  My gcc
configuration command is:

~/gcc-3.2.1/configure --prefix=/tools/linux/gcc-3.2.1 \
        --with-gnu-as --with-as=/tools/linux/bin/as \
        --with-gnu-ld --with-ld=/tools/linux/bin/ld \
        --enable-languages=c++

Where /tools/linux/bin was where I installed binutils.

Here is a simple testcase, where I define a trivial class in a header
file and a a cxx file, and instantiate it on the stack from another
cxx file.

  Makefile:
      GCC = /tools/linux/gcc-3.2.1
      %.o: %.cxx
              $(GCC)/bin/g++ -g -g3 -c $<
      classref.o: classref.cxx classdef.h
      classdef.o: classdef.cxx classdef.h
      classref: classref.o classdef.o
              $(GCC)/bin/g++ -o $@ $?
      clean:
              rm -f *.o
  classdef.h:
      class MyClass
      {
      public:
        MyClass();
        ~MyClass();

      private:
        int m1;
        int m2;
      };
  classdef.cxx
      #include "classdef.h"

      MyClass::MyClass()
      {
        m1 = 0;
        m2 = 5;
      }

      MyClass::~MyClass()
      {
        m1 = -1;
      }
  classref.cxx:
      #include "classdef.h"

      int main()
      {
        MyClass mc;
        return 0;
      }

My latest observation is that it seems I can now set breakpoints on a
constructor or destructor's entrance by specifying its full signature
on the command line (aided by TAB).  However, I cannot set breakpoints
on any line in the constructor or destructor via C-x space from emacs.

Here is an annotated gdb session:
    Current directory is /home/cds/josh/chacks/
    GNU gdb 5.3
    Copyright 2002 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 "i686-pc-linux-gnu"...
    (gdb) b MyClass::MyClass
    [0] cancel
    [1] all
    [2] MyClass at classdef.cxx:4
    [3] MyClass at classdef.cxx:4
    > 1
    Breakpoint 1 at 0x804855e: file classdef.cxx, line 4.
    Note: breakpoint 1 also set at pc 0x804855e.
    Breakpoint 2 at 0x804855e: file classdef.cxx, line 4.
    warning: Multiple breakpoints were set.
    warning: Use the "delete" command to delete unwanted breakpoints.

It seems to me I have only one constructor defined here, and if there
is an artifact of the compilation system that makes there be two copies
of that then that should be hidden from me by the debugger somehow.  But
this is not an ideal world and I'd be happy if after saying "all" this
just worked in some fashion...

    (gdb) r
    Starting program: /home/cds/josh/chacks/classref 

    Program exited normally.

It seemed to set the breakpoint but it blasted right through.
Now I'll try to set a breakpoint on the first line of the constructor,
which I would usually do from Emacs via C-x space.

    (gdb) b classdef.cxx:5
    Breakpoint 3 at 0x804856c: file classdef.cxx, line 5.
    (gdb) r
    Starting program: /home/cds/josh/chacks/classref 

    Program exited normally.

That didn't work either.  Let me try a line in the destructor:

    (gdb) b classdef.cxx:11
    Breakpoint 4 at 0x80485ac: file classdef.cxx, line 10.
    (gdb) r
    Starting program: /home/cds/josh/chacks/classref 

    Program exited normally.

Again that seemed to get set but it didn't work.  Now I'll try
setting a breakpoint in the constructor entrance by specifying
its full signature:

    (gdb) b MyClass::MyClass()
    Breakpoint 5 at 0x8048588: file classdef.cxx, line 4.
    (gdb) r
    Starting program: /home/cds/josh/chacks/classref 

    Breakpoint 5, MyClass (this=0xbffff610) at classdef.cxx:4
    (gdb) c
    Continuing.

    Program exited normally.

OK, that seemed to work fine.  But it's kind of limiting to only be
able to set breakpoints on constructor entry, nad not be able to get a
breakpoint set somewhere deep in the constructor.  Sometimes
constructors are not trivial.  My workaround is to move the guts of
the constructor into some other function, which is not very pleasant
if it takes a long time to re-run the testcase or even re-link.

    (gdb) b MyClass::~MyClass
    the class `MyClass' does not have destructor defined
    Hint: try 'MyClass::~MyClass<TAB> or 'MyClass::~MyClass<ESC-?>
    (Note leading single quote.)

This is surprising because I'm pretty sure this used to work in way
earlier versions of g++ and gdb.

    (gdb) b 'MyClass::~MyClass()' 
    Breakpoint 6 at 0x80485c8: file classdef.cxx, line 10.
    (gdb) dis 5
    (gdb) r
    Starting program: /home/cds/josh/chacks/classref 

    Breakpoint 6, ~MyClass (this=0xbffff610) at classdef.cxx:11
    (gdb) c
    Continuing.

    Program exited normally.
    (gdb) 

So it looks like destructors have the same limitation as constructors.
I can break on entry by specifying the full signature on the
breakpoint command line, but I can't break on line #s within the
destructor.  Again that is very useful and it's unfortunate if I have
to move my destructor guts into an auxiliary function to accomodate
the debugger limitations.

I haven't enough experience with this configuration yet to know
whether there are still issues with structure printing.  It seems
that may have improved with gdb 5.3.  Thanks!

Daniel Jacobowitz writes:
 > On Mon, Dec 23, 2002 at 05:39:43PM -0500, Joshua D. Marantz wrote:
 > > Hello,
 > > 
 > > We are having trouble debugging C++ code.  Are there a number of
 > > outstanding issues
 > 
 > Hundreds, I sometimes think.
 > 
 > > gdb 5.2.1, gdb 5.3
 > > g++ 3.1.1, 3.2, 3.2.1
 > > g++ compile options "-g", "-g3", "-ggdb", "-gstabs", "-gstabs+", "-gdwarf-2"
 > > SGI STL & STLport 4.5.3
 > > RedHat 7.3 & Solaris 9
 > 
 > I highly recommend using just -g and GCC 3.2.1; that'll give you
 > DWARF-2.  -g3 is also good.
 > 
 > > Symptoms include:
 > > 
 > >  - breakpoints in constructors do not work.  gdb says they get set successfully,
 > >    but they do not actually break.  This occurs whether the constructors are
 > >    inline or out-of-line.
 > 
 > This generally works, although with DWARF-2 it's dodgy.  The problem is
 > well understood and I haven't completely made up my mind what to do
 > about it yet.
 > 
 > >  - casting on the command line does not work -- yields a syntax error
 > 
 > Never seen this; there are problems with naming types that might be
 > causing it, I suppose...
 > 
 > >  - printing contents of instances of STL classes sometimes crashes
 > 
 > This should not happen in GDB 5.3.
 > 
 > >  - frequent gdb crashes (sorry this is so vague...)
 > 
 > Nor should this, although I know of at least one (calling functions in
 > a breakpoint's command list isn't fixed yet).
 > 
 > >  - when compiling with -gstabs+, I can print most structures, but I can't
 > >    call class methods from gdb.
 > >  - when compiling with -gdwarf-2, I can call class methods from gdb, but I can't
 > >    print most structures
 > 
 > OK, that's really odd.
 > 
 > >  - calling global functions from the debugger takes a long time and uses
 > >    a lot of memory.  calling class methods is fast however.  
 > 
 > I swear I'd resolved this.  Must be a new problem.
 > 
 > >  - it is difficult to call template methods from the debugger
 > 
 > Yes.
 > 
 > > All these issues were not present using g++ 2.8.1 and gdb 4.17.  In
 > > that environment most things worked well  Although gdb 4.17 did crash
 > > a little too often, it was much more functional.
 > 
 > It had nothing to do with GDB.  C++ was a simpler thing, then.  A lot
 > simpler.
 > 
 > > We can't go back to those old tools because our C++ & STL usage goes
 > > beyond the capabilities of g++ 2.8.1 & 2.9.*.
 > > 
 > > I can give testcases for all these things but it's really pretty
 > > basic C++ debugging.
 > > 
 > > Is this enough information?  Is there a path through these tools that
 > > works -- e.g. config options, versions, etc?
 > 
 > I'd appreciate small testcases for every one of these problems, if you
 > can manage it.  We'll see what we can do.
 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer