From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7156 invoked by alias); 1 May 2003 02:13:57 -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 7143 invoked from network); 1 May 2003 02:13:56 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 1 May 2003 02:13:56 -0000 Received: from [192.168.1.159] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b4) with ESMTP-TLS id 3753725; Wed, 30 Apr 2003 22:13:42 -0400 Date: Thu, 01 May 2003 02:13: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: carlton@bactrian.org, drow@mvista.com, gdb@sources.redhat.com, pkoning@equallogic.com To: Michael Elizabeth Chastain From: Daniel Berlin In-Reply-To: <200304301443.h3UEhopp000864@duracef.shout.net> Message-Id: <7F30EFA8-7B7A-11D7-8FE3-000A95A34564@dberlin.org> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00000.txt.bz2 On Wednesday, April 30, 2003, at 10:43 AM, Michael Elizabeth Chastain wrote: > Hi Daniel, > >> 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). > > I see what you mean. The ABI requirements are that there be two or > three > labels, and that the labels have different semantics. It was just an > assumption on my part that C++ compilers always emit distinct, > single-entry-point functions. It was just a "it's simple to implement this way, we'll optimize it later" thing, i think. You know, of the "why not keep the ABI implementation simple before we make it buggy" thought? :P > >> 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). > > This is possible but I am really not into this approach. > > I would rather expose to the user that one block of source code really > does generate several blocks of object code, and then handle > constructors > and destructors in a similar way that we handle inline functions. > After one initial surprise ('how come gdb sets 2-3 breakpoints when I > break on a constructor'), I think that users would actually understand > this model pretty well. > >> 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. > > Yeah. You call them hierarchical, but I think of them as different > types. The 'parent' here is of type 'source breakpoint'. The > 'subs' are of type 'object code breakpoint'. > > The current model is that a 'source breakpoint' and an 'object code > breakpoint' have a 1-1 relationship. We could separate the types and > then a source breakpoint could have a 1-many relationship with a > list of object code breakpoints. > > So your vision is a tree of nodes, all of the same type, and my vision > is of fixed depth 2, where level 1 is type SB, and level 2 is type OCB. > An SB has a list of OCB's and that's the whole structure. > > Is this making sense? > Yup. But i was thinking that the problem with a flattened tree like that is that it requires more work when checking breakpoints, which can be expensive See, we can easily test whether we are possibly within the range of a level 1 breakpoint by keeping track of the upper/lower bounds, even in your scheme (I say possibly since it could be multiple disjoint ranges, so we mihgt not *really* be in the bounds, but it's an optimization to not look at 2+ level breakpoints to see which we hit when it's impossible that we hit any of them) However, in your case, we'll need a linear walk of all the level 2+ to determine whether we are in range of any of them. O(n) If it's still organized as a multi-level binary tree (kept in some sort of sorted order), we only have to check log N of the breakpoints. If you breakpoint a heavily constructed object and set a condition on it, we might hit this thing a billion times, so it can add up quickly. >> ... (since i imagine in some extremely complex case, one could want to >> have a subbreakpoint consisting of subbreakpoints) ... > > Mmmmm, what would be a use case for that? If there is a real use case > than my simple two-level structure would be inadequate. I thought of a separate use of a BP hierarchy yesterday, which is handling inlined code (since it also may appear in multiple places, and if the user breaks on a source line that's inlined, he wants it to stop in all the copies) It led me just now to think of a use case: Inlined code in Inlined code. In that case, you *could* flatten the tree into 2 levels, but it's easier to build it as a subtree of a subtree (since we do a lot of debug reading recursively, and don't know where we came from), so unless the flattening was done in the l2breakpoint_add or whatever automatically, this might be problematic. > >> (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". > > Yes, this sounds good to me. Again in terms of "source breakpoint" > and "object code breakpoint", it becomes very simple: > > by definition, only an object code breakpoint can actually be > executed > gdb usually translates the OCB back to a SB for display > > Michael C