From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19163 invoked by alias); 15 Feb 2004 01:14:59 -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 19154 invoked from network); 15 Feb 2004 01:14:58 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 15 Feb 2004 01:14:58 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AsAs5-0004t4-RW; Sat, 14 Feb 2004 20:14:57 -0500 Date: Sun, 15 Feb 2004 01:14:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: gdb Subject: Re: constructors and DW_AT_MIPS_linkage_name Message-ID: <20040215011457.GA18740@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: 2004-02/txt/msg00146.txt.bz2 On Fri, Feb 13, 2004 at 09:59:30AM -0800, David Carlton wrote: > I was just looking at the .debug_info for the example given in PR > 1553, and I was surprised to see the following (some bits have been > deleted) > The weird thing is that operator= gets a linkage name, but the > constructors don't. I don't think we're prepared to deal with this; > it would explain some weirdnesses that I've seen elsewhere, where > trying to look up a class returns that class's constructor instead. > > Is this a known GCC issue? (The above is with GCC 3.2; for GCC > mainline, the debug info for A isn't there at all, but that's a > separate issue.) If so, in what circumstances does it occur? Hi David, You have rediscovered the cloned constructors "bug". The constructor referenced in the debug information actually is an abstract instance, and the two concrete instances reference that die via DW_AT_abstract_origin. Any cloned constructor or destructor will show this behavior. The finding-constructors-instead-of-classes thing is actually only tangentially related. At least, the last time I ran into it, it was. We do not walk the DW_AT_abstract_origin, or have a mangled name, so we assume it's a toplevel function named Classname. I thought this no longer happened... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer