This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++/Java regressions


David Carlton <carlton@kealia.com> writes:

> -KFAIL: gdb.cp/templates.exp: ptype T5<int> (PRMS: gdb/1111)
> -KFAIL: gdb.cp/templates.exp: ptype T5<int> (PRMS: gdb/1111)
> +FAIL: gdb.cp/templates.exp: ptype T5<int>
> +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<int>' test fails because gdb prints `type =
namespace T5<int>'.  I don't think this is because of the demangler.
I think it's because
1) gdb finds a DWARF entry for T5<int>::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<int>' as a possible namespace

Then when gdb goes to look up T5<int>, 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<int>" 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]