From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2025 invoked by alias); 30 Apr 2003 05:20:07 -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 2018 invoked from network); 30 Apr 2003 05:20:07 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 30 Apr 2003 05:20:07 -0000 Received: from [192.168.1.159] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b4) with ESMTP-TLS id 3752018; Wed, 30 Apr 2003 01:20:06 -0400 Date: Wed, 30 Apr 2003 05:20:00 -0000 Subject: Re: breakpoints in constructors Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: drow@mvista.com, pkoning@equallogic.com, carlton@bactrian.org, gdb@sources.redhat.com To: Michael Elizabeth Chastain From: Daniel Berlin In-Reply-To: <200304300436.h3U4aRGX025659@duracef.shout.net> Message-Id: <662F2E4E-7ACB-11D7-8FE3-000A95A34564@dberlin.org> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00341.txt.bz2 On Wednesday, April 30, 2003, at 12:36 AM, Michael Elizabeth Chastain wrote: > Can I de-lurk for a minute? > > gcc 2.95.3 had a single object code function for each constructor, > with a hidden flag to indicate its "in-charge-ness". I always thought > that was much nicer for debugging. > > But gcc 3.X's multi-object-code implementation is mandated by the > multi-vendor ABI, which will make it harder. No it isn't. It's not required multi-object-code, it's only required that it does the right thing when called with a certain name (not the same at all, since one can just make up the symbols for the constructors that start at the right points in the "one object code constructor" function, without even having to make stub functions with gotos in them. Just multiple symbol names and one object code). One can also have "one object code implementation" with labels and use gotos and stub functions if you like. Or one can have three copies of the object code. It's not like even with three copies, that this is a laborious task. It just means that you set multiple breakpoints. One way is to make one "visible" breakpoint and 2 "hidden" breakpoints. This is a bit ugly, unless you special case the breakpoint printouts so that it says the one "visible" breakpoint is at pc x, y, z, rather than just x (the code to do this is probably ugly too in this method). Another way is to do this is make it all invisible to the user, but still have "hidden" breakpoints is to make breakpoints have an associate set of methods, where they perform this magic internally. You could also just make a hierarchy of breakpoints and avoid the magic methods and hiding altogether. You have one parent breakpoint named "Foo:Foo" that just consists of 3 sub-breakpoints, each at the right place in the constructor. Only non-hidden top level breakpoints (since i imagine in some extremely complex case, one could want to have a subbreakpoint consisting of subbreakpoints) are visible, and thus, Foo:Foo is visible in an info breakpoints printout, but it's sub-breakpoints aren't (You can either just make it print "exists at multiple pc's, or recursively print out the pc's of the sub breakpoints). Hitting one of the subbreakpoints doesn't require any magic, since what we say is that we've hit the parent breakpoint, "Foo:Foo". --Dan