RFA: Please review the new C++ demangler patch

[Zack Weinberg]

"H. J. Lu" <hjl@lucon.org> writes:

>> > There will be only one source with my patches applied. Both libiberty
>> > and libstdc++ will use the one in demangler. During the demangler
>> > build, it will remove the old one in libiberty and put the new one
>> > in.
>> 
>> I don't understand what you mean by "remove the old one".
>
> ar -d ..../libiberty.a cp-demangle.o
> ar rc ..../libiberty.a demangle.o

Ick.  There must be a better way.

>> to build libiberty after libstdc++, which may be a problem on some
>> targets.
>
> I said build "demangler", not libiberty, after libstdc++.

Yah, but if there is no actual need to build libiberty before
libstdc++ this is just needless additional complexity.  Even if
libiberty *is* needed before libstdc++ on some target, I think I'd
rather that we figure out how to change that.

> It uses $(LN_S), which should do the right thing. FWIW, we did the
> same thing when libstdc++ used the old demangler in libiberty. I don't
> see how it becomes an issue today.

Fair 'nuff.

>> > In fact, the object files in libiberty and libstdc++ are different
>> > since they are compiled with different compiler options.
>> 
>> Why?
>
> The one in libiberty only supports the C interface without C++ support,
> like RTTI and exeception. Also it uses its own allocator and dynstring
> so that it can be used as a C function. Otherwise, you can put it in
> libiberty. But you don't want to do that in libstdc++.

Better we break up the demangler into "libiberty only" and "libstdc++
extra functionality", then.

zw