From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7340 invoked by alias); 3 Dec 2001 21:52:20 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7305 invoked from network); 3 Dec 2001 21:52:19 -0000 Received: from unknown (HELO localhost.localdomain) (62.30.164.150) by sources.redhat.com with SMTP; 3 Dec 2001 21:52:19 -0000 Received: (from jason@localhost) by localhost.localdomain (8.11.6/8.11.6) id fB3Lne114553; Mon, 3 Dec 2001 21:49:40 GMT X-Authentication-Warning: localhost.localdomain: jason set sender to jason@redhat.com using -f To: gdb-patches@sources.redhat.com Cc: gcc@gcc.gnu.org, Jason Merrill Subject: Re: [RFA/stabs reader] Fix v3 duplicate constructors problem References: <20011203154836.A28821@nevyn.them.org> From: Jason Merrill In-Reply-To: <20011203154836.A28821@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 3 Dec 2001 15:48:36 -0500") Date: Mon, 03 Dec 2001 13:52:00 -0000 Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-12/txt/msg00082.txt.bz2 >>>>> "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? Jason