how canonical are template names?

how canonical are template names?

[David Carlton]

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.

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.

Here's the differences in question, taken from gdb.logs in testsuite
runs (with control-M's stripped).  I'll do it test by test, listing
the current output first and my new output second.

ptype fvpchar
type = class Foo<volatile char*> {
  public:
    int x;
    volatile char *t;

    volatile char * foo(int, char volatile*);
}
(gdb) PASS: gdb.c++/templates.exp: ptype fvpchar

ptype fvpchar
type = class Foo<char volatile*> {
  public:
    int x;
    volatile char *t;

    volatile char * foo(int, char volatile*);
}
(gdb) FAIL: gdb.c++/templates.exp: ptype fvpchar

**** 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
ptype Bar
type = class Bar<int,33> {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Bar
ptype bint
type = class Bar<int,33> {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) PASS: gdb.c++/templates.exp: ptype bint
ptype bint2
type = class Bar<int,1> {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) PASS: gdb.c++/templates.exp: ptype bint2
ptype Baz
type = class Baz<int,'s'> {
  public:
    int x;
    int t;

    int baz(int, int);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Baz
ptype bazint
type = class Baz<int,'s'> {
  public:
    int x;
    int t;

    int baz(int, int);
}
(gdb) PASS: gdb.c++/templates.exp: ptype bazint
ptype bazint2
type = class Baz<char,'a'> {
  public:
    int x;
    char t;

    char baz(int, char);
}
(gdb) PASS: gdb.c++/templates.exp: ptype bazint2
ptype Qux
type = class Qux<char,&string> {
  public:
    int x;
    char t;

    char qux(int, char);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Qux
ptype quxint
type = class Qux<int,&string> {
  public:
    int x;
    int t;

    int qux(int, int);
}
(gdb) PASS: gdb.c++/templates.exp: ptype quxint
ptype Spec
type = class Spec<int,char> {
  public:
    int x;

    int spec(char);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Spec
ptype siip
type = class Spec<int,int*> {
  public:
    int x;

    int spec(int*);
}
(gdb) PASS: gdb.c++/templates.exp: ptype siip
ptype Garply<int>
type = class Garply<int> {
  public:
    int x;
    int t;

    int garply(int, int);
}
(gdb) PASS: gdb.c++/templates.exp: ptype Garply<int>
ptype Garply<Garply<char> >
type = class Garply<Garply<char> > {
  public:
    int x;
    Garply<char> t;

    Garply<char> garply(int, Garply<char>);
}
(gdb) PASS: gdb.c++/templates.exp: ptype Garply<Garply<char> >
print Garply<Garply<char> >::garply
$4 = {Garply<char> (Garply<Garply<char> > * const, int, Garply<char>)} 0x8049516 <Garply<Garply<char> >::garply(int, Garply<char>)>
(gdb) FAIL: gdb.c++/templates.exp: print Garply<Garply<char> >::garply
break Garply<Garply<char> >::garply
Breakpoint 5 at 0x8049528: file gdb.c++/templates.cc, line 696.
(gdb) PASS: gdb.c++/templates.exp: break Garply<Garply<char> >::garply
testcase ./gdb.c++/templates.exp completed in 7 seconds

		=== gdb Summary ===

# of expected passes		16
# of unexpected failures	6
# of expected failures		5
Executing on host: /extra/gdb/mirror/src/gdb/testsuite/../../gdb/gdb -nw --command gdb_cmd    (timeout = 300)
spawn /extra/gdb/mirror/src/gdb/testsuite/../../gdb/gdb -nw --command gdb_cmd 
GNU gdb 2003-01-09-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
/extra/gdb/mirror/src/gdb/testsuite/../../gdb/gdb version  2003-01-09-cvs -nx

runtest completed at Fri Jan 10 12:51:33 2003

**** New

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
ptype Bar
type = class Bar<int, 33> {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Bar
ptype bint
type = class Bar<int, 33> {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) FAIL: gdb.c++/templates.exp: ptype bint
ptype bint2
type = class Bar<int, 1> {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) FAIL: gdb.c++/templates.exp: ptype bint2
ptype Baz
type = class Baz<int, 115> {
  public:
    int x;
    int t;

    int baz(int, int);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Baz
ptype bazint
type = class Baz<int, 115> {
  public:
    int x;
    int t;

    int baz(int, int);
}
(gdb) FAIL: gdb.c++/templates.exp: ptype bazint
ptype bazint2
type = class Baz<char, 97> {
  public:
    int x;
    char t;

    char baz(int, char);
}
(gdb) FAIL: gdb.c++/templates.exp: ptype bazint2
ptype Qux
type = class Qux<char, &(string)> {
  public:
    int x;
    char t;

    char qux(int, char);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Qux
ptype quxint
type = class Qux<int, &(string)> {
  public:
    int x;
    int t;

    int qux(int, int);
}
(gdb) FAIL: gdb.c++/templates.exp: ptype quxint
ptype Spec
type = class Spec<int, char> {
  public:
    int x;

    int spec(char);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Spec
ptype siip
type = class Spec<int, int*> {
  public:
    int x;

    int spec(int*);
}
(gdb) FAIL: gdb.c++/templates.exp: ptype siip
ptype Garply<int>
type = class Garply<int> {
  public:
    int x;
    int t;

    int garply(int, int);
}
(gdb) PASS: gdb.c++/templates.exp: ptype Garply<int>
ptype Garply<Garply<char> >
type = class Garply<Garply<char> > {
  public:
    int x;
    Garply<char> t;

    Garply<char> garply(int, Garply<char>);
}
(gdb) PASS: gdb.c++/templates.exp: ptype Garply<Garply<char> >
print Garply<Garply<char> >::garply
$5 = {Garply<char> (Garply<Garply<char> > * const, int, Garply<char>)} 0x8049516 <Garply<Garply<char> >::garply(int, Garply<char>)>
(gdb) FAIL: gdb.c++/templates.exp: print Garply<Garply<char> >::garply
break Garply<Garply<char> >::garply
Breakpoint 5 at 0x8049528: file gdb.c++/templates.cc, line 696.
(gdb) PASS: gdb.c++/templates.exp: break Garply<Garply<char> >::garply
testcase ./gdb.c++/templates.exp completed in 7 seconds

		=== gdb Summary ===

# of expected passes		9
# of unexpected failures	13
# of expected failures		5
Executing on host: /extra/gdb/dictionary/src/gdb/testsuite/../../gdb/gdb -nw --command gdb_cmd    (timeout = 300)
spawn /extra/gdb/dictionary/src/gdb/testsuite/../../gdb/gdb -nw --command gdb_cmd 
GNU gdb 2002-12-23-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
/extra/gdb/dictionary/src/gdb/testsuite/../../gdb/gdb version  2002-12-23-cvs -nx

runtest completed at Fri Jan 10 12:45:54 2003

Re: how canonical are template names?

[David Carlton]

On 10 Jan 2003 13:19:45 -0800, David Carlton
<carlton@math.Stanford.EDU> said:

[ Whoops! ]

Sorry, if you just got a message titled "how canonical are template
names?", I accidentally sent that in the middle of composing it; the
real message will come in a bit.

David Carlton
carlton@math.stanford.edu

Re: how canonical are template names?

[Daniel Jacobowitz]

On Fri, Jan 10, 2003 at 07:06:53PM -0600, Michael Elizabeth Chastain wrote:
> Since a C++ parser is a bitch of a thing to write, is there any chance
> that Mark Mitchell's new C++ parser can be re-used in gdb?
> 
> The interesting part would be doing name resolution out of the
> symbol table information rather than internal compiler information.

This is something that I _definitely_ intend to pursue.  In order to do
it we'd have to find a way to add the flexibility GDB needs without
impacting the performance of the C++ parser....

Of course, for this to become a reality is sorta way down my list;
it'll require some fundamental architecturing we don't have.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: how canonical are template names?

[Michael Elizabeth Chastain]

Since a C++ parser is a bitch of a thing to write, is there any chance
that Mark Mitchell's new C++ parser can be re-used in gdb?

The interesting part would be doing name resolution out of the
symbol table information rather than internal compiler information.

Michael C

Re: how canonical are template names?

[Michael Elizabeth Chastain]

David C writes:
> 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.

templates.exp has issues.  :(  I'm working on a rewrite but it's on
the back burner right now.  You'll have to hand-analyze the results,
which I see you've done.

In fact, I'd like to just write a brand new templates test file,
include all the useful testing from the old one, and then strangle
the old one.

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

GDB is okay here.

> type = class Baz<int, 115> {

GDB is incorrect here.  sz is of type 'char' so it should be printed
like that.

* Current:

> type = class Qux<char, &(string)> {

This is probably a judgement call.  My opinion is that it's legal for
gdb to emit this.  It's annoying but we have much worse problems to fix,
so just eat it and go on to the other 570 open PR's.  I would like to
accept the parens for another 3-5 years, and we can revisit them once
gcc 2 is no longer supported, stabs is dead, and so on.

I would file a PR about the '115' that should be a character 's'
and let the others go.  My two cents.

Michael C

Re: how canonical are template names?

[David Carlton]

On Fri, 10 Jan 2003 15:33:02 -0800, Stan Shebs <shebs@apple.com> said:

> One goal for all GDB expression and type evaluation is to pass the
> cut-n-paste test - the debugger should be able to take anything in
> the source code and come up with the same interpretation as the
> compiler.  Anything less is a quick trip to user hell - manually
> expanding macros, trying to guess how to phrase a cast, executing
> function bodies line by line because function calls don't work.

> Of course, we'll always fall short of the ideal.  In the specific
> cases you mention, it sounds like some parser smartening is in
> order, and all the faults should be PRs.

I agree with all of this.

David Carlton
carlton@math.stanford.edu

Re: how canonical are template names?

[Stan Shebs]

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.
>
>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.
>
One goal for all GDB expression and type evaluation is to pass
the cut-n-paste test - the debugger should be able to take anything
in the source code and come up with the same interpretation as the
compiler.  Anything less is a quick trip to user hell - manually
expanding macros, trying to guess how to phrase a cast, executing
function bodies line by line because function calls don't work.

Of course, we'll always fall short of the ideal.  In the specific
cases you mention, it sounds like some parser smartening is in
order, and all the faults should be PRs.

Stan

Re: how canonical are template names?

[David Carlton]

On Fri, 10 Jan 2003 16:55:13 -0500, Daniel Jacobowitz <drow@mvista.com> said:
> On Fri, Jan 10, 2003 at 01:42:07PM -0800, David Carlton wrote:

>> 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.

All right, then I won't worry about it too much for now.

Which makes me happy: at least in the DWARF-2 case, I think I'm
finally producing all the symbols I want.  And lookup_symbol (and its
new friend, lookup_symbol_namespace) behave correctly.  And blocks
know about namespace scope.  Probably some other happy things are
happening, too.

So, unless I'm going crazy, the only remaining important item on my To
Do list is the other symbol-accessing functions.  Who knows; maybe
I'll have some RFC's/RFA's for you and Elena by the end of the month.
It would be nice...

David Carlton
carlton@math.stanford.edu

Re: how canonical are template names?

[Daniel Jacobowitz]

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

how canonical are template names?

[David Carlton]

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.

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.

Here's the differences in question, taken from gdb.logs in testsuite
runs.  I'll show the differences test by test, marking the current
output with "* Current:" my new output with "* Branch:", and my
discussion of differences with "* Discussion:".

* Current:

ptype fvpchar
type = class Foo<volatile char*> {
  public:
    int x;
    volatile char *t;

    volatile char * foo(int, char volatile*);
}
(gdb) PASS: gdb.c++/templates.exp: ptype fvpchar

* Branch:

ptype fvpchar
type = class Foo<char volatile*> {
  public:
    int x;
    volatile char *t;

    volatile char * foo(int, char volatile*);
}
(gdb) FAIL: gdb.c++/templates.exp: ptype fvpchar

* Discussion:

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


* 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 *'.)


* 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.


* 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.


* 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.


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.)

David Carlton
carlton@math.stanford.edu