RFA: Please review the new C++ demangler patch

[Joe Buck]

On Wed, Jun 25, 2003 at 10:13:14PM -0700, H. J. Lu wrote:
> Do you have any suggestions? The main problem is demangler, which
> is [part of libiberty], depends on libstdc++ and libstdc++ depends
> on libiberty. But demangler only needs the header files from libstdc++.
> Is there a way out?

Possibility 1: make the demangler a separate directory.  It can then be
built after libiberty and libstdc++ are built.  It would in effect be its
own library; care should be taken to assure that the resulting code is
self-contained.  This feels cleanest, but impact on gdb and binutils might
be an issue.  Of course, a gdb-builder could simply built against his/her
installed copy of libstdc++ (or even against some competing compiler's
standard C++ library) assuming that there is a C++ compiler on the
system.  We would use the libstdc++ in the same tree if present, otherwise
look for the system version, just as we do for other tools when we have
the option of building a whole tree.

Possibility 2: use -I flags during the libiberty build to point to the
relevant headers in the libstdc++ tree (that is, before they are
installed).  This feels ugly.

Possibility 3: make the demangler self-contained by writing a mini-library
to cover the aspects of <vector> and <string> that are used in the
demangler, but leave it as C++.  This might not be as hard as it looks.

Possibility 4: rewrite the whole new demangler in C.  This is a risky
undertaking, and I wouldn't be surprised if it takes a while to get all
the new buffer overflows and crashes out.  Letting the <vector> and
<string> classes do the memory management eliminates much of that risk.

I think that #1 is easiest to maintain going forward.