From: Paul Koning <pkoning@equallogic.com>
To: drow@mvista.com
Cc: carlton@bactrian.org, gdb@sources.redhat.com
Subject: Re: breakpoints in constructors
Date: Tue, 29 Apr 2003 20:45:00 -0000 [thread overview]
Message-ID: <16046.58450.847887.962016@pkoning.dev.equallogic.com> (raw)
In-Reply-To: <20030424145034.GA14226@nevyn.them.org>
>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> 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.
paul
next prev parent reply other threads:[~2003-04-29 20:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-18 20:04 David Carlton
2003-04-24 14:50 ` Daniel Jacobowitz
2003-04-24 22:02 ` Paul Koning
2003-04-25 0:30 ` Daniel Jacobowitz
2003-04-29 20:45 ` Paul Koning [this message]
2003-04-29 21:24 ` Daniel Jacobowitz
2003-04-30 19:04 ` Michael Eager
2003-04-30 19:11 ` Paul Koning
2003-04-30 19:19 ` Daniel Jacobowitz
2003-04-30 4:36 Michael Elizabeth Chastain
2003-04-30 5:20 ` Daniel Berlin
2003-04-30 14:44 Michael Elizabeth Chastain
2003-05-01 2:13 ` Daniel Berlin
2005-12-15 14:06 Breakpoints " Amit Kale
2005-12-26 7:52 ` Amit Kale
2005-12-27 4:07 ` Jim Blandy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16046.58450.847887.962016@pkoning.dev.equallogic.com \
--to=pkoning@equallogic.com \
--cc=carlton@bactrian.org \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).