From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27345 invoked by alias); 26 Nov 2003 04:04:54 -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 27329 invoked from network); 26 Nov 2003 04:04:50 -0000 Received: from unknown (HELO yosemite.airs.com) (209.128.65.135) by sources.redhat.com with SMTP; 26 Nov 2003 04:04:50 -0000 Received: (qmail 12719 invoked by uid 10); 26 Nov 2003 04:04:49 -0000 Received: (qmail 23211 invoked by uid 500); 26 Nov 2003 04:04:42 -0000 From: Ian Lance Taylor To: David Carlton Cc: gdb Subject: Re: C++/Java regressions References: Date: Wed, 26 Nov 2003 04:04:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-11/txt/msg00250.txt.bz2 David Carlton writes: > -KFAIL: gdb.cp/templates.exp: ptype T5 (PRMS: gdb/1111) > -KFAIL: gdb.cp/templates.exp: ptype T5 (PRMS: gdb/1111) > +FAIL: gdb.cp/templates.exp: ptype T5 > +FAIL: gdb.cp/templates.exp: ptype t5i I looked into these, although I know that other people have looked into them already. I recreated the problem with current gcc. It was happening with the older gcc I was using before. For me, the `ptype T5' test fails because gdb prints `type = namespace T5'. I don't think this is because of the demangler. I think it's because 1) gdb finds a DWARF entry for T5::T5(int) 2) gdb creates a psymbol for this entry 3) gdb calls the possible namespace code in cp-namespace.c 4) that code enters the symbol `T5' as a possible namespace 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. I can avoid the problem with this patch, but I'm sure this is not right approach. Index: cp-namespace.c =================================================================== RCS file: /cvs/src/src/gdb/cp-namespace.c,v retrieving revision 1.7 diff -u -p -r1.7 cp-namespace.c --- cp-namespace.c 13 Nov 2003 19:34:02 -0000 1.7 +++ cp-namespace.c 26 Nov 2003 03:55:58 -0000 @@ -675,7 +675,7 @@ static int check_possible_namespace_symbols_loop (const char *name, int len, struct objfile *objfile) { - if (name[len] == ':') + if (name[len] == ':' && memchr (name, '<', len) == NULL) { int done; int next_len = len + 2; 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. Ian