From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1482 invoked by alias); 30 Apr 2003 14:44: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 1457 invoked from network); 30 Apr 2003 14:44:11 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 30 Apr 2003 14:44:11 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.9/8.12.9) with ESMTP id h3UEhpO6024014; Wed, 30 Apr 2003 09:43:51 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h3UEhp16000865; Wed, 30 Apr 2003 09:43:51 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.9/8.12.9/Submit) id h3UEhopp000864; Wed, 30 Apr 2003 10:43:50 -0400 Date: Wed, 30 Apr 2003 14:44:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200304301443.h3UEhopp000864@duracef.shout.net> To: dberlin@dberlin.org Subject: Re: breakpoints in constructors Cc: carlton@bactrian.org, drow@mvista.com, gdb@sources.redhat.com, pkoning@equallogic.com X-SW-Source: 2003-04/txt/msg00344.txt.bz2 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. > 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? > ... (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. > (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