Demangler update?

[Ian Lance Taylor]

   Date: Fri, 14 Apr 2000 08:24:39 +0200
   From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>

   > I'm personally not convinced that dynamic loading support is necessary
   > at all.  It seems like the wrong approach.  Rather than requiring
   > dynamic loading, we should follow the Unix way: use a small program.
   > It should be possible to write any demangler to filter the input
   > stream, as c++filt does.  Then demangling symbols is simply a matter
   > of running them through a program.  pipe/fork/exec is a standard fully
   > portable Unix paradigm.  Dynamic loading adds no special capabilities
   > here.

   I'd take that a step further: Why is it that external extensibility is
   needed at all?

There is a reasonable argument for external extensibility.

The mangling scheme does change over time, and it can change with each
release of the compiler.  In practice new manglings seem to get added
pretty often.

The binutils and gcc are not released in synch.  If you have a new
compiler, an older binutils may well be unable to demangle the names
generated by the new compiler.

The fix is to have the compiler provide a demangling program (it
already does, in fact) and to have the binutils simply use it.

   >> Compaq C++ depends on this patch.

   Putting my Free Software hat on, I think this is not a good idea at
   all. Why couldn't binutils support the Compaq C++ mangling directly,
   just as it understands the HP aCC mangling?

   To me, this sounds like Compaq does not want to share the algorithm
   for demangling. Why should binutils support their C++ compiler, then?

I agree.  This is an issue which Compaq ought to address somehow.

   Having a better selection of the demangling algorithm to chose, and
   perhaps allowing simpler integration of other algorithms (on a source
   code) level is a different matter - I'm all for it.

I agree.

Ian