This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: breakpoints in constructors

>>>>> "Daniel" == Daniel Jacobowitz <> writes:

 Daniel> On Fri, Apr 18, 2003 at 01:04:46PM -0700, David Carlton
 Daniel> wrote:
 >> I might have some time over the next few weeks (/months) to work
 >> on the "breakpoints in constructors" issue.  Daniel: clearly
 >> you've thought about this already, so if you happen to have time
 >> to do a bit of a brain dump on the issue at some point, I'd
 >> appreciate it.

 Daniel> Sure.  First of all, a rough overview of the problem; might
 Daniel> as well keep everything in one place.

 Daniel> With the new GCC 3.x multi-vendor C++ ABI, constructors are
 Daniel> implemented as multiple functions: C1, the complete object
 Daniel> constructor [in-charge] C2, the base object constructor
 Daniel> [not-in-charge] C3, the allocating constructor [not currently
 Daniel> used]

 Daniel> Similarly for destructors - most of the rest of this message
 Daniel> applies to destructors too.  The base constructor is
 Daniel> generally called for the base objects of a derived class,
 Daniel> esp. with virtual inheritance; it's been a while since I
 Daniel> looked at exactly when.

 Daniel> GCC has chosen to implement this by duplicating the function,
 Daniel> including any user-provided code and any compiler-added code.
 Daniel> A better implementation would have one copy and labels for
 Daniel> multiple entry points, on systems where that is supported;
 Daniel> that's temporarily tabled pending a better description of the
 Daniel> GCC tree structure to describe multiple entry points.

I looked at a few examples to see how they differ.  Didn't see any
where the two constructors that gcc generates differ at all.  Ditto
for the two (in charge vs. not in charge) destructors.

The "deleting" constructor does what the name suggests, it frees the
item at the end.  Since the difference is at the end, that doesn't
sound like a case where multiple entry points can help.

Couldn't one constructor/destructor call another, so that there one
"bottom level" constructor or destructor where all three variants
eventually end up?  Then that would be the one you'd want to match
when you set a breakpoint by name or by line.

The only drawback I can see is that you'd see an extraneous frame in
the callstack.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]