From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26687 invoked by alias); 30 Apr 2003 19:19:24 -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 26668 invoked from network); 30 Apr 2003 19:19:24 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 30 Apr 2003 19:19:24 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19Ax76-0007r2-00; Wed, 30 Apr 2003 14:19:32 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19Ax6l-0002xX-00; Wed, 30 Apr 2003 15:19:11 -0400 Date: Wed, 30 Apr 2003 19:19:00 -0000 From: Daniel Jacobowitz To: Michael Eager Cc: Paul Koning , carlton@bactrian.org, gdb@sources.redhat.com Subject: Re: breakpoints in constructors Message-ID: <20030430191910.GA11133@nevyn.them.org> Mail-Followup-To: Michael Eager , Paul Koning , carlton@bactrian.org, gdb@sources.redhat.com References: <20030424145034.GA14226@nevyn.them.org> <16046.58450.847887.962016@pkoning.dev.equallogic.com> <20030429212434.GA1637@nevyn.them.org> <3EB01CC8.CD952D8B@eagercon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EB01CC8.CD952D8B@eagercon.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00348.txt.bz2 On Wed, Apr 30, 2003 at 11:58:16AM -0700, Michael Eager wrote: > 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.) Ah, yes, you're right. But you end up with the extra call if you compile with -O0. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer