From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20607 invoked by alias); 3 Dec 2001 22:29:01 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20482 invoked from network); 3 Dec 2001 22:28:58 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 3 Dec 2001 22:28:58 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16B1ad-0000vm-00; Mon, 03 Dec 2001 17:29:31 -0500 Date: Mon, 03 Dec 2001 14:29:00 -0000 From: Daniel Jacobowitz To: Jason Merrill Cc: gdb-patches@sources.redhat.com, gcc@gcc.gnu.org Subject: Re: [RFA/stabs reader] Fix v3 duplicate constructors problem Message-ID: <20011203172931.A2512@nevyn.them.org> Mail-Followup-To: Jason Merrill , gdb-patches@sources.redhat.com, gcc@gcc.gnu.org References: <20011203154836.A28821@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2001-12/txt/msg00069.txt.bz2 On Mon, Dec 03, 2001 at 09:49:39PM +0000, Jason Merrill wrote: > >>>>> "Daniel" == Daniel Jacobowitz writes: > > [redirected to gcc list, rather than libstdc++] > > > I tracked down the annoying duplication of constructors using G++ 3.0 with > > stabs. The problem is that all the clones of the constructor are emitted, > > so there really are two of them. > > Yep. > > > The obvious thing to do to fix this in GCC (and I'd like it fixed in GCC) > > would seem to be checking DECL_ABSTRACT_ORIGIN like the Dwarf frontend does > > instead of DECL_ABSTRACT. That works for eliminating the duplicates and > > creating the names we need, but the mangled name in debug info is the > > "*INTERNAL*" version if we do that. I'd like to emit the name of the > > constructor and the mangled name of the complete object constructor, > > ideally. C++ people, does that sound right? Or feasible? > > It's certainly feasible; when we see the abstract version, look ahead for a > clone and use its mangled name. > > The thing is, we want the debugger to treat them as the same function, so > that setting a breakpoint on the signature actually sets one on each and > the like. I suppose that ideal will not be affected by your change, both > because (I assume) it doesn't work now and because we use the demangled > names for most purposes anyway. > > What does GDB actually use the member function information for? What > impact would this change have, other than the output of ptype? Right now, the big thing is probably member function calls. If the constructor is called from GDB, we want to get the complete object constructor. I'm not 100% sure this is even possible, though. I hadn't considered setting breakpoints on all of them. That's very difficult; suppose I look at an assembly listing for a constructor and tell it to break on a particular line. How can I figure out source line information for every constructor? I've no idea what happens in this case. Perhaps it is best to continue emitting them and ignore them until we support them in GDB. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer