Demangling broken (was: Re: [PATCH] Demangler woes with current CVS and type names)

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> Date: Tue, 29 Jan 2002 23:07:10 -0500
> From: Phil Edwards <phil@jaj.com>

> This patch makes the older demangler call cp_demangle_type in a non-_Z
> situation, same as the newer one.  The cp_demangle_type routine wasn't
> being compiled if c++filt was being built; this patch relaxes that.
> Also, mangling_new() was given a second parameter a full year ago,
> but cp_demangle_type was still calling the single-parameter version...
> I've updated it but am not sure if the 'style' parameter is correct.
> 
> With this patch, the non-_Z names used in the testcase above can be
> demangled by c++filt.  I've added an entry to libiberty's testsuite,
> which fails before and passes after.

And here's another testsuite entry, for a bug exposed or
introduced by that patch:

Index: demangle-expected
===================================================================
RCS file: /cvs/src/src/libiberty/testsuite/demangle-expected,v
retrieving revision 1.7
diff -p -c -r1.7 demangle-expected
*** demangle-expected	2002/01/31 02:21:27	1.7
--- demangle-expected	2002/01/31 09:36:29
*************** _Utf58_0_1__1_2147483647__2147483648
*** 2594,2596 ****
--- 2594,2599 ----
  --format=gnu-v3
  St9bad_alloc
  std::bad_alloc
+ --format=gnu-v3
+ data
+ data

The --format=gnu-v3 parameter isn't necessary; default works
too.  When you run the test, you'll see "data" demangled as
"double".  Doh.  This breaks binutils, as seen in its
testresults, for example ld-discard/extern fails.  Tests fail
like that above; <symbol> in messages like "undefined reference
to <symbol>" is munged, referring to a basic C/C++ type instead
of a symbol.

It's a double doh (no pun intended, I think): For binutils, we
just want to demangle identifiers (not types), so for that use,
the _Z check should be there to avoid spurious demangling.
Tracing through the demangler, I see it's just the "d" character
demangled, so demangling replaced the whole string with a
partial demangling.  Sorry, no obvious fix jumped up at me.

> Tested on i686-pc-linux-gnu.  Opinions?

Since you asked, I'm of the opinion that

1) The partial-demangling bug be fixed
2) The new demangle-a-type functionality be controllable
   with an option flag, say (a new) DMGL_TYPE in
   include/demangle.h (alternatively, a DMGL_NO_TYPE).
   Perhaps that means changing the (/adding a new) interface for
   the v3 demangler; I don't see it taking flags.
3) Unless 2 happens before, this patch be reverted on the
   binutils 2.12 branch right after it branches.

> 2002-01-29  Phil Edwards  <pme@gcc.gnu.org>
> 
> 	* cp-demangle.c (cp_demangle_type):  Do not protect with IN_LIBGCC2.
> 	(cplus_demangle_v3):  Mimic __cxa_demangle and fall back on
> 	cp_demangle_type.
> 	* testsuite/demangle-expected:  New gnu-v3 test.

brgds, H-P