Re: So what is wrong with v3 C++

[Michael Elizabeth Chastain <chastain@cygnus.com>]

Dan Berlin writes:
> 1. Template functions (names or types) have return types encoded,
>    with the exceptions listed below.

Okay, we must comply with the ABI, then.

> You seem to want to get rid of return types from mangled names for
> templates. This ain't gonna ever happen. It's done on purpose, it's
> not an accident.

No, first I want to know what the spec requires.  The ABI spec wants the
information to be present in the mangled name.  Now follow the information
flow:

  mangled name -> demangled name (demangler)
  demangled name -> user visible and user matchable names (gdb)

I accept the ABI spec, and I'm comfortable with the demangler preserving
all the information including the return type.

We still have to figure out what to do if the user types:

  (gdb) break add_two_values

... when add_two_values is a template.

One option is to propagate this "return type in the name" all the way
through to the user, and mention it in the documentation.  So the
user really would have to type:

  (gdb) break 'int add_two_values<int,int>TAB

> LD, c++filt, nm, objdump, etc all use it.
> GDB seems to *depend* on it more, but this is not a good thing. We
> depend on mangled names too much.

nm, objdump, and c++filt just use demangling in their output.
As far as I know, ld operates the same way.  Does it ever demangle a name
and use the result for anything except error printing?

gdb is the only tool I know where people type in names and the tool
has to match against demangled forms.

If you are suggesting that the demangler should return a nice tree
of information, instead of gdb doing its own re-parsing, I'm in favor
of that.

> I've already rewritten the dwarf2 reader, including the scope work.
> There would be little point in JimB rewriting it again.

I saw the patch.

Do you have any test results, or plans for getting it tested?

Michael