From: Ian Lance Taylor <ian@wasabisystems.com>
To: David Carlton <carlton@kealia.com>
Cc: gdb <gdb@sources.redhat.com>
Subject: Re: C++/Java regressions
Date: Wed, 26 Nov 2003 04:04:00 -0000 [thread overview]
Message-ID: <m3vfp7vkpy.fsf@gossamer.airs.com> (raw)
In-Reply-To: <yf28ym5w7mg.fsf@hawaii.kealia.com>
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
next prev parent reply other threads:[~2003-11-26 4:04 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-25 1:37 David Carlton
2003-11-25 1:48 ` The demangler was rewritten from scratch! Andrew Cagney
2003-11-25 3:58 ` C++/Java regressions Ian Lance Taylor
2003-11-26 4:04 ` Ian Lance Taylor [this message]
2003-11-26 15:32 ` Daniel Jacobowitz
2003-11-26 21:05 ` Ian Lance Taylor
2003-11-26 21:11 ` David Carlton
2003-11-26 21:12 ` Daniel Jacobowitz
2003-11-26 21:32 ` Ian Lance Taylor
2003-12-01 16:45 ` Daniel Jacobowitz
2003-11-30 2:57 ` Jim Blandy
2003-11-30 3:12 ` Daniel Jacobowitz
2003-11-25 4:44 Michael Elizabeth Chastain
2003-11-25 17:54 ` Ian Lance Taylor
2003-11-25 14:49 Michael Elizabeth Chastain
2003-11-25 15:06 ` Daniel Jacobowitz
2003-11-25 15:33 Michael Elizabeth Chastain
2003-11-25 17:06 Michael Elizabeth Chastain
2003-11-25 17:14 ` David Carlton
2003-11-25 17:59 ` Daniel Jacobowitz
2003-11-26 21:18 Michael Elizabeth Chastain
2003-11-26 21:33 ` Ian Lance Taylor
2003-11-26 21:44 Michael Elizabeth Chastain
2003-11-26 22:21 ` Ian Lance Taylor
2003-11-26 22:28 ` Daniel Jacobowitz
2003-11-26 22:34 ` Ian Lance Taylor
2003-11-26 22:48 Michael Elizabeth Chastain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3vfp7vkpy.fsf@gossamer.airs.com \
--to=ian@wasabisystems.com \
--cc=carlton@kealia.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox