From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15456 invoked by alias); 30 Apr 2003 19:04:12 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15429 invoked from network); 30 Apr 2003 19:04:11 -0000 Received: from unknown (HELO siaar1aa.compuserve.com) (149.174.40.9) by sources.redhat.com with SMTP; 30 Apr 2003 19:04:11 -0000 Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.12.9/8.12.7/SUN-REL-2.7) id h3UIuMsx017977 for gdb@sources.redhat.com; Wed, 30 Apr 2003 14:56:22 -0400 (EDT) Received: from eagercon.com (lax9-tgn-lwi-vty12.as.wcom.net [216.193.29.12]) by siaar1aa.compuserve.com (8.12.9/8.12.7/SUN-REL-2.7) with ESMTP id h3UItrdd017556; Wed, 30 Apr 2003 14:55:55 -0400 (EDT) Message-ID: <3EB01CC8.CD952D8B@eagercon.com> Date: Wed, 30 Apr 2003 19:04:00 -0000 From: Michael Eager X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Paul Koning , carlton@bactrian.org, gdb@sources.redhat.com Subject: Re: breakpoints in constructors References: <20030424145034.GA14226@nevyn.them.org> <16046.58450.847887.962016@pkoning.dev.equallogic.com> <20030429212434.GA1637@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00346.txt.bz2 Daniel Jacobowitz wrote: > > On Tue, Apr 29, 2003 at 04:45:06PM -0400, Paul Koning wrote: > > >>>>> "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. > > Wow, Paul, you're really on top of this one. Yes, that's what Apple > implemented, and I'm looking over their patches right now :) There are > some quirks in the implementation which are throwing me for a loop. > > The constructors will differ in some cases involving virtual bases; > that's what they're for. I think that you can generate a jump rather than a call, so there is no extraneous call frame on the stack. (I think that's what the Apple patch does, actually.) -- Michael Eager Eager Consulting eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077