Re: PATCH: Support the new demangler written in C++

[Nathanael Nerode <neroden at twcny dot rr dot com>]

>> Seventh, if we're doing this, is there a reason we still have 
>> cplus-dem.o (the *old old* demangler), or am I missing something?
You missed the point; that's the "old old" demangler, as opposed to 
cp-demangle.c which is the "old" demangler (but is newer than 
cplus-dem.c).  Surely we don't need *three* demanglers?

>The new demangler needs a working C++ compiler, which may not be
>available when
>
>1. There is no working C++ compiler. In that case, we use the old
>demangler.
This is really not acceptable.  Either we use the new demangler or we 
don't.  We could have it as a configure-time option (with an error 
message if the new demangler is chosen and there's no C++ compiler), 
but having it decided secretly based on the build environment is 
unacceptably opaque.  It's not acceptable for GDB to magically build 
with the "good" demangler if there's a C++ compiler around and with 
the "bad" demangler if there isn't; can you imagine the confusing bug 
reports?  "It works for me with the same snapshot."  "Did you have a C++ 
compiler in your environment?"  Ick, ick, ick, ick, ick, ick, ick.

>2. We are building the C++ compiler and libstdc++. But the new
>demangler needs libstdc++, which depends on libiberty. We build
>the target demangler after libstdc++ is done.

So why are we putting the demangler in libiberty then?  This is dumb and 
wrong since it means there will be two versions of libiberty built, the 
"pre-demangler" and the "post-demangler", and programs which use it 
will get a random one.  Oh, right, you dealt with that by 
seriously overdeclaring Make dependencies.  Well, that's simply the 
Wrong Way to Do It.

Let me describe the options acceptable to me again:

1. Make a C demangler which works.  Put it in libiberty.  (Nobody is 
volunteering.)

2. Make the demangler part of libstdc++-v3.  Make any programs which use 
it require libstdc++-v3.  (Considered unacceptable by GDB people, I 
believe.)

3. Make the demangler a fully independent directory which must be built
after libstdc++-v3; require it to be built (or separately installed as 
'libdemangle.a' or some such) by the programs which want it and don't 
want libstdc++-v3.  This is what I hoped you were doing.  (This will 
mean that GDB requires a C++ compiler to build, which may or may not be
acceptable.  Or it could be done as I mentioned above, with GDB using 
it at runtime if it's installed and not demangling otherwise, but that 
requires major interface redesign, again.)

4. Make the C++ demangler totally independent of libstdc++-v3 so that it 
can be compiled with a freestanding C++ compiler.  Then the C++ 
demangler can go into libiberty and live there happily, and replace both 
of the existing ones.  Libiberty can be built before libstdc++-v3, eliminating 
bootstrapping problems in the native bootstrap build.  

Non-GCC builds or ordinary crosses would require a C++ compiler.
For build!=host, a C++ compiler from the build to the host will be 
needed; if GCC's libraries are being built, a C++ compiler from the 
build to the target will also be needed.  These are all probably 
acceptable, although not entirely desirable.

5. Find a free C++ to C compiler along the lines of CFRONT; make the C++ 
demangler a source file which is turned into a C file by maintainers, 
and include and build the C file in the tarball, accomplishing option 1. 
This would probably not work because I don't think there is a free C++ 
to C compiler.

6.  Redesign the interface of programs using the demangler to find and 
use it at runtime.  (Either put it in libstdc++-v3 or in a separate 
libdemangle.)  Then GDB would always be compiled with demangler 
support, and would not need a C++ compiler to build, but would 
require libstdc++ or libdemangle to be installed at runtime in order to 
demangle C++ names.  I quite like this option but it might be a 
difficult lot of work on several programs.

7. Use one of the options which requires a C++ compiler at build time, 
but add a configure option --without-demangler to allow it to be omitted.
Rather similar to #6.  Or add a --with-broken-demangler to use the 
broken demangler.  Either way, make these *non-default* options so that 
the user knows what she's getting herself into.


There are probably a couple of other possible solutions.  Sadly, the one 
that keeps being pushed at us is not a solution; having variant versions 
of programs with different demanglers, one of them broken, depending on 
random aspects of the environment, is really not good.

-- 
Nathanael Nerode  <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html