Re: Breakpoints in ctor and gcc 3.x

[Jim Blandy <jimb@redhat.com>]

<Cedric.Pillonel@swisscom.com> writes:
> This bug is old and I'm surprised that it still has not been fixed
> !!!  Is there any workaround?  When will it be fixed ? I think it is
> a serious one since you can't debug your ctor or dtor !

The problem is that GCC emits two copies of a constructor: one that's
called to initialize a direct instance of the class (the "in charge"
constructor), and one to initialize the class's portion of an instance
of some derived class (the "not-in-charge" constructor).  They deal
with virtual base classes differently, and there may be some other
things.  But GDB only sets a breakpoint in one copy --- whichever one
appears first in the code.

At the moment, GDB assumes that each breakpoint set by the user can be
implemented by a single break instruction or hardware breakpoint.  To
handle breakpoints on constructors, you need to set two low-level
breakpoints --- one on the in-charge, and one on the not-in-charge.
This is going to be a lot of work to fix, and there were other, also
serious, C++ bugs folks decided to work on first.

Simply knowing the in-charge vs. not-in-charge distinction may help
out.  For example, if you're trying to debug the constructor for some
class's base class, but GDB is setting its breakpoint on the in-charge
constructor, you could try instantiating the base class directly, to
hit the breakpoint.  Or the reverse. 

You could try setting the breakpoint by raw address: use "disassemble"
and x/i to find the code address of the constructor instance you
actually want to debug, and use "break *EXPR" to set the breakpoint
there.