This is the mail archive of the
mailing list for the GDB project.
Re: Breakpoints in ctor and gcc 3.x
- From: Jim Blandy <jimb at redhat dot com>
- To: <Cedric dot Pillonel at swisscom dot com>
- Cc: <gdb at sources dot redhat dot com>, <gdb-prs at sources dot redhat dot com>
- Date: 01 Oct 2003 01:52:52 -0500
- Subject: Re: Breakpoints in ctor and gcc 3.x
- References: <57CE6CB990693A478C1106BBC91398BA7D559D@sxmbx04.corproot.net>
> 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