Re: how canonical are template names?

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Jan 10, 2003 at 01:42:07PM -0800, David Carlton wrote:
> I'm testing a patch on my branch that tries to figure out when a class
> lives inside a namespace by looking at the demangled names of the
> methods of the classes.

Oooh, ooh, I've done this.  All of this sounds familiar... I just got
too distracted to do anything about it.  As usual, I'm glad to see you
following up on these things.
> 
> When I tested the patch, I saw some regressions in
> gdb.c++/templates.exp.  But, on looking at the situation further, I'm
> not sure that they qualify as regressions.  Basically, there are
> different ways to write the same types; it turns out that G++'s debug
> info and the demangler choose different ways in some circumstances.
> 
> In an ideal world, maybe GDB would always print types in one canonical
> way and allow users as much flexibility as possible in how they input
> types.  But, for now, it seems quite reasonable to allow GDB to print
> types however it wishes and to require users to input types the same
> way that GDB outputs them in some circumstances.  Usually, users can
> figure out what name GDB thinks a templated class has by calling
> 'ptype' on a variable of the appropriate type.

I'm not so sure; given that GDB prints them in different ways at
different times, this can get pretty darned confusing.

I won't comment on all the individual differences, but you may want to
look at demangler output for these, in 2.x and 3.x; it's enlightening. 
Just run nm -C on testcases.

> Here, the new output switches the 'char' and 'volatile'.  It's still
> the same type.

I've been thinking that we may want to hand-canonicalize these; I'm
still torn as to whether we should do so in the same way that v3 does
or in the same way that the currently-in-use-for-this-ABI demangler
does.  In any case we want to be able to canonicalize so that we can be
flexible in what we accept.  That's important to me, but not until down
the road.

> * Current:
> 
> print Foo<volatile char *>::foo
> No symbol "Foo<volatile char *>" in current context.
> (gdb) FAIL: gdb.c++/templates.exp: print Foo<volatile char *>::foo
> 
> * Branch:
> 
> print Foo<volatile char *>::foo
> $4 = {volatile char *(Foo<volatile char*> * const, int, volatile char *)} 0x80493be <Foo<char volatile*>::foo(int, char volatile*)>
> (gdb) FAIL: gdb.c++/templates.exp: print Foo<volatile char *>::foo
> 
> * Discussion:
> 
> I have no idea what bizarre interaction between the parser and
> templates is causing the new version to print something useful in this
> situation even though the current version doesn't.  (For what it's
> worth, the current version does print something useful if you omit the
> space in 'char *'.)

The demangler changes at work again.

> * Current:
> 
> ptype Bar
> type = class Bar<int,33> {
>   public:
>     int x;
>     int t;
> 
>     int bar(int, int);
> }
> (gdb) XFAIL: gdb.c++/templates.exp: ptype Bar
> 
> * Branch:
> 
> ptype Bar
> type = class Bar<int, 33> {
>   public:
>     int x;
>     int t;
> 
>     int bar(int, int);
> }
> (gdb) XFAIL: gdb.c++/templates.exp: ptype Bar
> 
> * Discussion:
> 
> Here, the new output puts spaces between template arguments.  (I have
> no idea what's up with the XFAIL: I haven't looked into that yet.)
> There are a few more examples that differ only by spaces (some of
> which turn PASS into FAIL rather than maintaining an XFAIL); I'll skip
> them.

Probably ditto.

> * Current:
> 
> ptype Baz
> type = class Baz<int,'s'> {
>   public:
>     int x;
>     int t;
> 
>     int baz(int, int);
> }
> (gdb) XFAIL: gdb.c++/templates.exp: ptype Baz
> 
> * Branch:
> 
> ptype Baz
> type = class Baz<int, 115> {
>   public:
>     int x;
>     int t;
> 
>     int baz(int, int);
> }
> (gdb) XFAIL: gdb.c++/templates.exp: ptype Baz
> 
> * Discussion:
> 
> Here, not only is there an extra space, but the character constant is
> printed using its numerical value.  There are a few more examples like
> this.

Note what the demangler does:
0804930a W Baz<char, (char)97>::baz(int, char)

I don't know what we want to do.

> * Current:
> 
> ptype Qux
> type = class Qux<char,&string> {
>   public:
>     int x;
>     char t;
> 
>     char qux(int, char);
> }
> (gdb) XFAIL: gdb.c++/templates.exp: ptype Qux
> 
> * Branch:
> 
> ptype Qux
> type = class Qux<char, &(string)> {
>   public:
>     int x;
>     char t;
> 
>     char qux(int, char);
> }
> (gdb) XFAIL: gdb.c++/templates.exp: ptype Qux
> 
> * Discussion:
> 
> Besides the space difference, there are parens around 'string'.  There
> are more examples like this, too.

Hmm; I don't know if this is a demangler shortcut or bug.  It may be
legitimate for more complex inner expressions.

> Those are the differences that the testsuite reveals.  Any opinions as
> to which of these should be considered serious, if any?  I'm leaning
> towards not worrying about any of them, but filing a low-priority PR
> about it just to get it into the database.  (The main reason for the
> latter is because it would be nice if input were a bit more flexible;
> I don't care so much about variations in GDB's output.)

I put a generally low priority on template debugging right now, so I'm
OK with this.  Somewhere along the line we'll need to do better.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer