RFA: Please review the new C++ demangler patch

[H. J. Lu]

On Thu, Jun 26, 2003 at 10:38:23AM -0700, Joe Buck wrote:
> 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.

My current patch does almost exactly that, except for the resulting
demengler is folded into libiberty. So that there is no change
required for any packages which expect demengler in libiberty.

> 
> 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.

Some header files are generated during libstdc++ build.

> 
> 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.

Why reinvent the wheel? Shouldn't the gcc developer time be better
spent on other things?

> 
> 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.

No argument here.


H.J.