From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7924 invoked by alias); 6 Dec 2001 18:18:28 -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 7604 invoked from network); 6 Dec 2001 18:17:55 -0000 Received: from unknown (HELO localhost.localdomain) (62.30.164.150) by sources.redhat.com with SMTP; 6 Dec 2001 18:17:55 -0000 Received: (from jason@localhost) by localhost.localdomain (8.11.6/8.11.6) id fB6IGsv09949; Thu, 6 Dec 2001 18:16:54 GMT X-Authentication-Warning: localhost.localdomain: jason set sender to jason@redhat.com using -f To: gcc@gcc.gnu.org Cc: Daniel Berlin Subject: Re: DWARF-2 and constructors/destructors References: <20011205225246.A10961@nevyn.them.org> From: Jason Merrill In-Reply-To: <20011205225246.A10961@nevyn.them.org> (Daniel Jacobowitz's message of "Wed, 5 Dec 2001 22:52:46 -0500") Date: Thu, 06 Dec 2001 10:39: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/msg00293.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: > Suppose you want to call a (non-virtual) method in C++, from something > with Dwarf-2 info. The only way to get the mangled name from the debug > info is DW_AT_MIPS_linkage_name. As Dan Berlin points out, The mangled name is already in the symbol table, if there's actually a definition of the method. Why does it need to be in the debug info as well? To call a non-virtual function, we're only interested in its address. The debug information doesn't enter into it. This applies to all functions, of course, not just ctors/dtors. The DW_AT_MIPS_linkage_name stuff was a hack to make dwarf2 work with the existing stabs-oriented code with minimal effort; it would save a lot of space if we could get rid of it. Jason