public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
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


  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).