From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7945 invoked by alias); 26 Nov 2003 15:32:35 -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 7927 invoked from network); 26 Nov 2003 15:32:35 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 26 Nov 2003 15:32:35 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AP1ec-0002oE-Rr for ; Wed, 26 Nov 2003 10:32:34 -0500 Date: Wed, 26 Nov 2003 15:32:00 -0000 From: Daniel Jacobowitz To: gdb Subject: Re: C++/Java regressions Message-ID: <20031126153234.GA10644@nevyn.them.org> Mail-Followup-To: 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-11/txt/msg00258.txt.bz2 On Tue, Nov 25, 2003 at 11:04:41PM -0500, Ian Lance Taylor wrote: > Then when gdb goes to look up T5, it finds the DWARF psymbol for > the class itself, but it also finds that the symbol might be a > namespace. It then decides that it is a namespace. That sounds like the bit that's wrong. If it found a psymbol for the class why does it decide to call it a namespace? > The problem with t5i, besides some demangler changes which have > already been addressed, is that gdb doesn't recognize that a > constructor function is, in fact, a constructor. That's because the > code in c-typeprint.c does this: > > char *method_name = TYPE_FN_FIELDLIST_NAME (type, i); > char *name = type_name_no_tag (type); > int is_constructor = name && strcmp (method_name, name) == 0; > > and this: > > char *physname = TYPE_FN_FIELD_PHYSNAME (f, j); > int is_full_physname_constructor = > is_constructor_name (physname) > || is_destructor_name (physname) > || method_name[0] == '~'; > > The first fails because name is "T5" and method_name is "T5". > The second fails because this is dealing with debugging information, > and gcc does not emit any physical symbol name information for class > constructors. > > This could be addressed by changing the simple test for is_constructor > to a more complex test which ignore the template arguments when > determining whether method_name was the same as name. Yes, I have a patch sitting here (for some time) which does this. It got mixed in with some other patches that aren't ready for prime-time yet. I'm considering a routine for canonicalization of C++ demangled names. That's the only way we're going to get templates.exp to start working robustly. For cv-qualifiers it's fairly easy, and most of what gets mangled is to accomodate either space efficiency or linker character sets so that's not all so important. "Unsigned" <-> "unsigned int" is also easy. Template arguments can be a little harder so we may punt. Perhaps next month. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer