Re: So what is wrong with v3 C++

[Daniel Berlin <dan@cgsoftware.com>]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

>> >   gdb/7   cout << 1 doesn't work for c++
>> This one is bogus.
>> It does work.
>> I poitned this out on gdb.bugs.
> 
> No.  You pointed out that it works with dwarf2.  You acknowledged
> that it doesn't work with stabs.  
Ahh, yes, now i remember.

My bad.
> You wrote:
> 
>   http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=23&database=gdb
> 
>   As did I, look for the posting where i showed it worked for me with
>   dwarf2 on both ppc, and x86.
> 
>   It doesn't work on stabs for one of two reasons:
>   ....
> 
>> >   gdb/40  C++ template functions have return types in their names
>> Normal. They should.
>> Look at the ABI standard.
> 
> The problem is that a template function has a name such as
> "int add_two_values<int>(int, int)", whereas a normal function has a
> name such as "add_two_values(int, int)".  Note the return type at the
> beginning of the name.
> 
> Specifically:
> 
>   % c++filt
>   _Z14add_two_valuesIiET_S0_S0_
>   int add_two_values<int>(int, int)
>   _Z14add_two_valuesii
>   add_two_values(int, int)
> 
> This was also a problem with v2.
I'm telling you, it's done on purpose, it's not a bug.

> 
> I'm looking at section 5.1.2 of the ABI standard, "General Structure".
> The demangling grammar gets down to "unqualified source code identifier"
> in about ten productions, with no reference to the function return type.
> Can you quote me the part of the ABI standard that puts the return type
> before the name?

Before the name?
No.
In the name?
Sure.
Template functions always have the return type included.

"
 Whether the mangling of a function type includes the return type
 depends on the context and the nature of the function.
   The rules for deciding whether the return type is included are:
    1. Template functions (names or types) have return types encoded,
       with the exceptions listed below.
    2. Function types not appearing as part of a function name
       mangling, e.g. parameters, pointer types, etc., have return
       type encoded, with the exceptions listed below.
    3. Non-template function names do not have return types encoded.
   The exceptions mentioned in (1) and (2) above, for which the return
   type is never included, are
     * Constructors.
     * Destructors.
     * Conversion operator functions, e.g. operator int.
"

Where the demangler places them is not going to be mandated by the ABI
standard.
Only when the return type of a function goes in the mangled name.

Function return types in C and C++ go before the function name in the
source, thus, this is where the demangler places them.

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.


>> libiberty already has demangler coverage for the demangler, why do we
>> need it in gdb as well?
> 
> Gdb is the #1 client of the demangler 

Really?
I just don't feel that way.

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.
> 
> The second reason is that libiberty/testsuite/demangle-expected has
> only five cases that start with "_Z", and they are all --format=java.
> So we actually have very little v3 coverage right now.
> 
> BTW, demangle.exp has 877 tests, but it covers four demangling styles:
> gnu, lucid, arm, and hp.  So we are looking at 200-300 new tests,
> not 900 new tests.

The difference is that the new demangler is much easier to debug, and
recursive descent on a known grammar, as a result, fixing bugs in it
are basically guaranteed to not cause other things mysterious to
happen.
Each grammar production is completely localized to one routine.

> 
>> >   gdb/59  static members in a base class confuse gdb
>> Fixed. with a valops change i made a while ago.
> 
> I just tried this with this week's builds, and I'm getting an error:
> 
>   (gdb) p pB
>   $1 = (B *) 0x8050538
>   (gdb) p *pB
>   Value can't be converted to integer.
> 
> Native Red Hat Linux 7, stabs, et cetera.

> 
> This is a different error than the bug reported in the PR.  Sigh.
Yup.

> 
>> These bugs were always there, v3 just exposes them a heck of a lot
>> more.  They used to be hard to see, and users would occasionally
>> complain.
>> Now it's right in their face, almost any time they use the standard
>> library.
> 
> Yeah.  I claim that "v3 is almost better than v2".  But if v2 was
> terrible, that still might not be very good.
> 
>>From a scheduling point of view, JimB can fix a lot of bugs before
> touching the dwarf2 reader.  From a release criteria point of view, I
> just don't know how much scope work is necessary to have a shippable
> 5.1.

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

> 
> Michael

-- 
"One time I went to a museum where all the work in the museum had
been done by children.  They had all the paintings up on
refrigerators.
"-Steven Wright