From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21445 invoked by alias); 24 Apr 2003 14:50:39 -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 21438 invoked from network); 24 Apr 2003 14:50:38 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 24 Apr 2003 14:50:38 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 198i3n-0000N0-00; Thu, 24 Apr 2003 09:50:51 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 198i3W-0003kZ-00; Thu, 24 Apr 2003 10:50:34 -0400 Date: Thu, 24 Apr 2003 14:50:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: gdb Subject: Re: breakpoints in constructors Message-ID: <20030424145034.GA14226@nevyn.them.org> Mail-Followup-To: David Carlton , gdb References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00292.txt.bz2 On Fri, Apr 18, 2003 at 01:04:46PM -0700, David Carlton 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. Sure. First of all, a rough overview of the problem; might as well keep everything in one place. With the new GCC 3.x multi-vendor C++ ABI, constructors are implemented as multiple functions: C1, the complete object constructor [in-charge] C2, the base object constructor [not-in-charge] C3, the allocating constructor [not currently used] Similarly for destructors - most of the rest of this message applies to destructors too. The base constructor is generally called for the base objects of a derived class, esp. with virtual inheritance; it's been a while since I looked at exactly when. GCC has chosen to implement this by duplicating the function, including any user-provided code and any compiler-added code. A better implementation would have one copy and labels for multiple entry points, on systems where that is supported; that's temporarily tabled pending a better description of the GCC tree structure to describe multiple entry points. So the end result is that we start with: class C { public: C(); }; C::C() { // do stuff } And there are two copies of that function. If we use the demangler in non-verbose mode, we get the same demangled name for both of them: C::C(). If we use it in verbose mode we get C::C[in-charge]() and C::C[not-in-charge](), but using verbose mode has other issues for GDB; it's too verbose/obscure in some places. So there are two interesting problems: - What happens when I say "break C::C"? - What happens when I say "break ", pointing at the "do stuff"? So that's the general problem. Ideally, when we say "break C::C" we will get multiple breakpoints automatically. Not to be confused with find_methods/decode_line_2! We'd still get a menu with two choices if there was a copy constructor and a default constructor; but choosing either one would place two breakpoints. What would this mean for "info breakpoints"? Would they be one breakpoint with multiple addresses or visible to the user as two breakpoints? I'd prefer the former but I believe there was some disagreement. I don't know what current art in other debuggers is; does anybody? Similarly when we say "break line", IMO, there should be multiple breakpoints. This is even harder; in optimized code we may have multiple ranges of PC for a particular line even in the same function (and IMO we should be placing more than one breakpoint in that case); here we have multiple ranges across different functions. Placing one user-visible breakpoint per range would get out of hand pretty fast. With the current breakpoint implementation even placing all the breakpoints would get out of hand pretty fast, since we remove all breakpoints from memory at each stop. I think that's fixable. [Assuming an improved breakpoint layer, can we place a breakpoint on every possible instruction in a line? With variable-length instructions this is very hard; with jump tables in text sections it might be downright impossible, since we don't know what is code and what isn't. Placing a breakpoint at the beginning of every distinct range, while not perfect, is still an improvement. However, it's kind of confusing. Stepping through optimized code you might hit the "one" breakpoint multiple times. Bears some thinking about.] All of this eventually ties in to debugging inlined functions and templated functions, which are harder versions of the same thing. Can't think of anything else at the moment... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer