Demangler update?

Demangler update?

[Ken Block USG]

H.J. submitted this patch for the demangler a while back and it has not
been checked in. The patch provides:

1) support for GNAT ada compiler.
2) adds a --style switch to a number of tools to allow them to specify
which demangler to be used.
3) It adds the ability to dynamic load a demangler that is shipped
independently.


Compaq C++ depends on this patch. What needs to be done to get this
demangler patch checked in?  If I redid this patch against the latest
snapshot and broke it down into smaller pieces, would somebody be
willing to check it in?


http://gcc.gnu.org/ml/gcc-patches/1999-10n/msg00258.html

Re: Demangler update?

[Ian Lance Taylor]

   Date: Thu, 13 Apr 2000 20:37:22 -0400
   From: Ken Block USG <block@zk3.dec.com>

   H.J. submitted this patch for the demangler a while back and it has not
   been checked in. The patch provides:

   1) support for GNAT ada compiler.
   2) adds a --style switch to a number of tools to allow them to specify
   which demangler to be used.
   3) It adds the ability to dynamic load a demangler that is shipped
   independently.


   Compaq C++ depends on this patch. What needs to be done to get this
   demangler patch checked in?  If I redid this patch against the latest
   snapshot and broke it down into smaller pieces, would somebody be
   willing to check it in?


   http://gcc.gnu.org/ml/gcc-patches/1999-10n/msg00258.html

First let me say that I think that the gcc/g++ maintainers are
responsible for the changes to libiberty.  I encourage them to
evaluate this patch and work to get some version of it checked in.  I
am not a gcc/g++ maintainer myself.

For myself, I think this patch definitely needs work.  I also think it
would help a lot to break it down, since there are several things
mixed into it.

The most problematical aspect to it is the dynamic loading support,
which is probably what you care about.

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.

If we are going to add dynamic loading, then it must be documented.
It must not be specific to GNU/Linux.  Special cases for compaq should
not be required, and should be completely eliminated from the code.
It makes no sense to introduce a brand new interface which permits
more flexibility in demangling and then make it inflexible.  The style
name should somehow automatically translate into the shared library to
use.

Other than the dynamic linking, I think it should be possible to get
most of this patch checked in.

Ian

Re: Demangler update?

[Martin v. Loewis]

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

AFAICT, the rationale is to allow binutils, in particular GNU ld, to
demangle Compaq C++ symbols. At least, that's how I understood

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

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.

Regards,
Martin

Re: Demangler update?

[Ken Block USG]

Ian Lance Taylor wrote:

> For myself, I think this patch definitely needs work.  I also think it
> would help a lot to break it down, since there are several things
> mixed into it.
>
> The most problematical aspect to it is the dynamic loading support,
> which is probably what you care about.

I will break the patch down and let people reject the dynamic loading
piece since it seems to be raising the most red flags. Atleast we could
minimize the divergance between the sourceware binutils and the
linux binutils.

I'll try to address the issues for the dynamic loading patch seperately.

Re: Demangler update?

[Ken Block USG]

"Martin v. Loewis" wrote:

> >> 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?
>
> 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.
>
> Regards,
> Martin

Compaq is more than happy to share our demangler algorithms. It is my
belief that the code is very complicated and not particularly well written
or robust and it would not serve anybody's interest to have it added to
libibierty. I suspect that even if we did open source it, the maintainers
would reject it. Furthermore, there is a work in progress to try and
develop an object model that will allow Compaq C++ and G++ to be
link compatible. When this is achieved, our demangler goes into the
garbage.

I've talked to my manangement and they have agreed to let me
publish our sources under the understanding that we still are
retaining the copyright and they cannot be redistributed. Look at
the code, if the maintainers of libiberty like the code and want to
incorrporate it into libiberty, then I will begin the process to get
the sources released.

This process will require getting a VP, the legal department, and
twhichever is harder Griffen in accounting or the mythical beast
to sign off, but I will do it, if that is what it will take to get support
for
Compaq C++ in binutils.

The sources are now available and for the next 48 hours at:

ftp://xfer.americas.digital.com/to_customer/demangler.tar.gz


After 48 hours, it will be available at

http://gnv.sourceforge.net/downloads/demangler.tar.gz .


We can address the architectual/implement objections seperately
from the philosophical ones.

Re: 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

Re: Demangler update?

[H . J . Lu]

On Fri, Apr 14, 2000 at 09:07:38AM -0700, Ian Lance Taylor wrote:
> 
> 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.
> 

As I have pointed out before, it may not work every well with
more than one version/release of C++ compilers, depending
on how c++filt is installed. When you type "c++filt", you may
not get the "c++filt" you want. c++filt should be installed just
like cc1plus and invoked by g++/c++ only. However, it still
doesn't solve the problem for gdb and binutils.


H.J.

Re: Demangler update?

[Ian Lance Taylor]

   Date: Fri, 14 Apr 2000 10:00:35 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   On Fri, Apr 14, 2000 at 09:07:38AM -0700, Ian Lance Taylor wrote:

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

   As I have pointed out before, it may not work every well with
   more than one version/release of C++ compilers, depending
   on how c++filt is installed. When you type "c++filt", you may
   not get the "c++filt" you want. c++filt should be installed just
   like cc1plus and invoked by g++/c++ only. However, it still
   doesn't solve the problem for gdb and binutils.

We have to face that problem somehow.  Dynamic loading doesn't solve
it either.

To put it another way, if we can solve the problem with dynamic
loading, then we can solve it with an external program.

In any case, we only need to fully solve the 90% case, in which there
is only one compiler around, while retaining enough flexibility to
handle unusual cases such as the one you describe.

Ian

Re: Demangler update?

[H . J . Lu]

On Fri, Apr 14, 2000 at 10:04:31AM -0700, Ian Lance Taylor wrote:
>    Date: Fri, 14 Apr 2000 10:00:35 -0700
>    From: "H . J . Lu" <hjl@lucon.org>
> 
>    On Fri, Apr 14, 2000 at 09:07:38AM -0700, Ian Lance Taylor wrote:
> 
>    > 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.
> 
>    As I have pointed out before, it may not work every well with
>    more than one version/release of C++ compilers, depending
>    on how c++filt is installed. When you type "c++filt", you may
>    not get the "c++filt" you want. c++filt should be installed just
>    like cc1plus and invoked by g++/c++ only. However, it still
>    doesn't solve the problem for gdb and binutils.
> 
> We have to face that problem somehow.  Dynamic loading doesn't solve
> it either.
> 
> To put it another way, if we can solve the problem with dynamic
> loading, then we can solve it with an external program.
> 
> In any case, we only need to fully solve the 90% case, in which there
> is only one compiler around, while retaining enough flexibility to
> handle unusual cases such as the one you describe.

I don't think my case is that unusual. As of today, on my Linux
box, there are C++ binaries linked with 4 different versions
of libstdc++, compiled with 4 different versions of g++.

I prefer DSO over external program because it is small and
has much less overhead. It is just my personal opinion.


H.J.

Re: Demangler update?

[Ian Lance Taylor]

   Date: Fri, 14 Apr 2000 10:20:46 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   > In any case, we only need to fully solve the 90% case, in which there
   > is only one compiler around, while retaining enough flexibility to
   > handle unusual cases such as the one you describe.

   I don't think my case is that unusual. As of today, on my Linux
   box, there are C++ binaries linked with 4 different versions
   of libstdc++, compiled with 4 different versions of g++.

I hope you aren't trying to argue that you are a typical user.  I
believe that most developers use one compiler which they rarely
change.

   I prefer DSO over external program because it is small and
   has much less overhead. It is just my personal opinion.

But we walk smack into portability issues.  gcc and the binutils work
on dozens of systems.  What's the point of a solution which only works
on some, or, the way you wrote it, exactly one?

I know that you mainly, or perhaps exclusively, care about GNU/Linux,
but you know that the GNU maintainers care about many more systems.
Providing a solution which solves a general problem in a way which
only works on GNU/Linux is not acceptable.  You know that.

I personally have no objection to dynamic loading being an option,
provided that it is clearly documented, and that all it takes to add a
new demangling option is to drop a new shared object into some
directory.

Ian

Re: Demangler update?

[David Starner]

On Fri, Apr 14, 2000 at 10:31:18AM -0700, Ian Lance Taylor wrote:
>    Date: Fri, 14 Apr 2000 10:20:46 -0700
>    From: "H . J . Lu" <hjl@lucon.org>
> 
>    > In any case, we only need to fully solve the 90% case, in which there
>    > is only one compiler around, while retaining enough flexibility to
>    > handle unusual cases such as the one you describe.
> 
>    I don't think my case is that unusual. As of today, on my Linux
>    box, there are C++ binaries linked with 4 different versions
>    of libstdc++, compiled with 4 different versions of g++.
> 
> I hope you aren't trying to argue that you are a typical user.  I
> believe that most developers use one compiler which they rarely
> change.

Debian Potato will ship with three versions of libstdc++ (libstdc++2.8,
libstdc++2.9-glibc2.1, libstdc++2.10) and four versions of libg++ 
(libg++2.8, libg++27, libg++2.8.1.3, libg++2.8.2-glibc2.1). I have
all three versions of libstdc++ around.

-- 
David Starner - dstarner98@aasaa.ofe.org
Only a nerd would worry about wrong parentheses with
square brackets. But that's what mathematicians are.
   -- Dr. Burchard, math professor at OSU

Re: Demangler update?

[Ken Block USG]

Ian Lance Taylor wrote:

>    Date: Fri, 14 Apr 2000 10:20:46 -0700
>    From: "H . J . Lu" <hjl@lucon.org>
>
>    > In any case, we only need to fully solve the 90% case, in which there
>    > is only one compiler around, while retaining enough flexibility to
>    > handle unusual cases such as the one you describe.
>
>    I don't think my case is that unusual. As of today, on my Linux
>    box, there are C++ binaries linked with 4 different versions
>    of libstdc++, compiled with 4 different versions of g++.
>
> I hope you aren't trying to argue that you are a typical user.  I
> believe that most developers use one compiler which they rarely
> change.
>
>    I prefer DSO over external program because it is small and
>    has much less overhead. It is just my personal opinion.
>
> But we walk smack into portability issues.  gcc and the binutils work
> on dozens of systems.  What's the point of a solution which only works
> on some, or, the way you wrote it, exactly one?
>
> I know that you mainly, or perhaps exclusively, care about GNU/Linux,
> but you know that the GNU maintainers care about many more systems.
> Providing a solution which solves a general problem in a way which
> only works on GNU/Linux is not acceptable.  You know that.
>
> I personally have no objection to dynamic loading being an option,
> provided that it is clearly documented, and that all it takes to add a
> new demangling option is to drop a new shared object into some
> directory.
>
> Ian

If you want to implement both, I can, but I'm not sure how well an
external program will work inside of gdb or similar programs.

So what do you do, open a pipe for the input and the output of the
filter, write the symbol you want to demangle, and then read it back
from the other end of the pipe. Do we run the program each time we want
to demangle a symbol or do we leave a demangler process active for
the duratation?

If you run a new program for each symbol, I think you are going to
definitely have efficiency problems. If you leave the program active
for the duration, will you have a caching problem? If you write the
symbol into the filter, when will it come out the other end? It will
definitely come out the other end when you close the pipe and I'd
assume it would come out the other end when you flush, but the
standard c++filter would not do that. Once again efficiency seems
questionable.

Also, I don't see how using dlopen is specific to Linux. It will work
on any platform that supports dlopen from within binaries that are
dynamically linked. That would even include Tru64, Linux, and
even VMS. What platforms would it not support and is it a
requirement to support all platforms or just as many as we can?

Re: Demangler update?

[Ian Lance Taylor]

   Date: Fri, 14 Apr 2000 13:48:29 -0400
   From: Ken Block USG <block@zk3.dec.com>

   So what do you do, open a pipe for the input and the output of the
   filter, write the symbol you want to demangle, and then read it back
   from the other end of the pipe.

That is what I would imagine.

   Do we run the program each time we want
   to demangle a symbol or do we leave a demangler process active for
   the duratation?

I would think we would leave the process around.

   If you run a new program for each symbol, I think you are going to
   definitely have efficiency problems. If you leave the program active
   for the duration, will you have a caching problem? If you write the
   symbol into the filter, when will it come out the other end? It will
   definitely come out the other end when you close the pipe and I'd
   assume it would come out the other end when you flush, but the
   standard c++filter would not do that. Once again efficiency seems
   questionable.

The standard filter in libiberty/cplus-dem.c already flushes its
output after every symbol.  The calling program would have to flush
after each symbol it writes, which is easy.

   Also, I don't see how using dlopen is specific to Linux. It will work
   on any platform that supports dlopen from within binaries that are
   dynamically linked. That would even include Tru64, Linux, and
   even VMS. What platforms would it not support and is it a
   requirement to support all platforms or just as many as we can?

Using dlopen is not specific to GNU/Linux.  HJ's patch is specific to
GNU/Linux, because it has #ifdef linux in it.

Using dlopen is a portability hassle, because even on systems which
support it you sometimes have to link against -ldl or perhaps other
libraries.  Not all systems have shared libraries, and of those not
all support dlopen.  gcc and the binutils work on a lot of systems.

Ian

Re: Demangler update?

[H . J . Lu]

On Fri, Apr 14, 2000 at 10:31:18AM -0700, Ian Lance Taylor wrote:
>    Date: Fri, 14 Apr 2000 10:20:46 -0700
>    From: "H . J . Lu" <hjl@lucon.org>
> 
>    > In any case, we only need to fully solve the 90% case, in which there
>    > is only one compiler around, while retaining enough flexibility to
>    > handle unusual cases such as the one you describe.
> 
>    I don't think my case is that unusual. As of today, on my Linux
>    box, there are C++ binaries linked with 4 different versions
>    of libstdc++, compiled with 4 different versions of g++.
> 
> I hope you aren't trying to argue that you are a typical user.  I
> believe that most developers use one compiler which they rarely
> change.
> 

3 out of 4 different versions of shared libstdc++ are provided
by Red Hat 6.2. They are parts of the libstdc++ 2.9.0-30 rpm. You
can say most if not all Red Hat users have similar installations
like me.


H.J.

Re: Demangler update?

[Ken Block USG]

Ian Lance Taylor wrote:

>    Date: Fri, 14 Apr 2000 13:48:29 -0400
>    From: Ken Block USG <block@zk3.dec.com>
>
>    So what do you do, open a pipe for the input and the output of the
>    filter, write the symbol you want to demangle, and then read it back
>    from the other end of the pipe.
>
> That is what I would imagine.
>
>    Do we run the program each time we want
>    to demangle a symbol or do we leave a demangler process active for
>    the duratation?
>
> I would think we would leave the process around.
>
>    If you run a new program for each symbol, I think you are going to
>    definitely have efficiency problems. If you leave the program active
>    for the duration, will you have a caching problem? If you write the
>    symbol into the filter, when will it come out the other end? It will
>    definitely come out the other end when you close the pipe and I'd
>    assume it would come out the other end when you flush, but the
>    standard c++filter would not do that. Once again efficiency seems
>    questionable.
>
> The standard filter in libiberty/cplus-dem.c already flushes its
> output after every symbol.  The calling program would have to flush
> after each symbol it writes, which is easy.
>
>    Also, I don't see how using dlopen is specific to Linux. It will work
>    on any platform that supports dlopen from within binaries that are
>    dynamically linked. That would even include Tru64, Linux, and
>    even VMS. What platforms would it not support and is it a
>    requirement to support all platforms or just as many as we can?
>
> Using dlopen is not specific to GNU/Linux.  HJ's patch is specific to
> GNU/Linux, because it has #ifdef linux in it.
>
> Using dlopen is a portability hassle, because even on systems which
> support it you sometimes have to link against -ldl or perhaps other
> libraries.  Not all systems have shared libraries, and of those not
> all support dlopen.  gcc and the binutils work on a lot of systems.
>
> Ian

OK, I'll look into providing patches to implement it both ways and see
which ones get accepted.

Re: Demangler update?

[Ian Lance Taylor]

   Date: Fri, 14 Apr 2000 11:03:22 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   >    > In any case, we only need to fully solve the 90% case, in which there
   >    > is only one compiler around, while retaining enough flexibility to
   >    > handle unusual cases such as the one you describe.
   > 
   >    I don't think my case is that unusual. As of today, on my Linux
   >    box, there are C++ binaries linked with 4 different versions
   >    of libstdc++, compiled with 4 different versions of g++.
   > 
   > I hope you aren't trying to argue that you are a typical user.  I
   > believe that most developers use one compiler which they rarely
   > change.

   3 out of 4 different versions of shared libstdc++ are provided
   by Red Hat 6.2. They are parts of the libstdc++ 2.9.0-30 rpm. You
   can say most if not all Red Hat users have similar installations
   like me.

Despite this, I believe my statement is correct as it stands.

But this is completely irrelevant, and I'm not going to comment
further on it.  Obviously if somebody can solve the whole problem,
then we should implement that.  Arguing about whether we need to solve
the whole problem is pointless.  Since you think we do, go ahead and
solve it.

It remains the case that if we can solve the whole problem with shared
libraries, then we can solve it with an external program.  The
suggested solutions are no different in this regard.

Ian

Re: Demangler update?

[Theodore Papadopoulo]

ian@zembu.com said:
> Using dlopen is a portability hassle, because even on systems which
> support it you sometimes have to link against -ldl or perhaps other
> libraries.  Not all systems have shared libraries, and of those not
> all support dlopen.  gcc and the binutils work on a lot of systems. 

Isn't libtool supposed do deal with this for us ???

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: Demangler update?

[Ian Lance Taylor]

   Date: Fri, 14 Apr 2000 20:22:01 +0200
   From: Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr>

   ian@zembu.com said:
   > Using dlopen is a portability hassle, because even on systems which
   > support it you sometimes have to link against -ldl or perhaps other
   > libraries.  Not all systems have shared libraries, and of those not
   > all support dlopen.  gcc and the binutils work on a lot of systems. 

   Isn't libtool supposed do deal with this for us ???

This might well be a solution.  I don't know the details about the
libtool dlopen support.  I don't know whether it works on systems
which do not support shared libraries at all.

Note that libiberty does not currently use libtool, and that as far as
I know the libtool dlopen support is not yet released.  Also,
libiberty is compiled in a limited cross configuration to provide
supporting functions for libstdc++.  Rather than cope with this, it
might be easier to lift any dynamic loading support out of libiberty.

Ian

Re: Demangler update?

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

On Apr 14, 2000, Ian Lance Taylor <ian@zembu.com> wrote:

> This might well be a solution.  I don't know the details about the
> libtool dlopen support.  I don't know whether it works on systems
> which do not support shared libraries at all.

It does.  But then, the benefit of simplifying upgrades H.J. wanted
can't be accomplished.  Using separate executables is the only way to
accomplish that.  At least, before libtool's libltdl (its portable
dlopening library) gains a self-relinking&re-exec()ing mechanism that
could be used to overcome the inability to dlopen() libraries.

> Note that libiberty does not currently use libtool, and that as far as
> I know the libtool dlopen support is not yet released.

It has been available since release 1.3.0 (the latest is 1.3.4)

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

Re: Demangler update?

[Martin v. Loewis]

> As I have pointed out before, it may not work every well with
> more than one version/release of C++ compilers, depending
> on how c++filt is installed. When you type "c++filt", you may
> not get the "c++filt" you want. c++filt should be installed just
> like cc1plus and invoked by g++/c++ only. However, it still
> doesn't solve the problem for gdb and binutils.

I agree. If the solution is to invoke c++filt, that could be invoked
just as well by the g++ driver, or collect2, or even by the user -
there is no need for libiberty creating new processes.

Adding new demanglers to -liberty is the right thing, IMO. However, I
dislike dynamic loading of them - this is an additional step that can
fail. You cannot easily move ld or gdb binaries around as you
currently can. The political issues of such extensibility are also a
strong reason for me to dislike it.

Regards,
Martin

Re: Demangler update?

[Martin v. Loewis]

> 3 out of 4 different versions of shared libstdc++ are provided
> by Red Hat 6.2. They are parts of the libstdc++ 2.9.0-30 rpm. You
> can say most if not all Red Hat users have similar installations
> like me.

We are getting off-topic here, but I think a single demangler works
for all those C++ compiler versions that you have installed. The only
minor problem I'm aware of is that array bounds mangling may differ.

Regards,
Martin

Re: Demangler update?

[Martin v. Loewis]

> It is my belief that the code is very complicated and not
> particularly well written or robust and it would not serve anybody's
> interest to have it added to libibierty.

Code in -liberty is of varying quality, usefulness, and authorship. So
I guess your code would fit in very well :-)

> I suspect that even if we did open source it, the maintainers would
> reject it.

I took a glance at the code. It is quite a lot of code, but it appears
to be self-contained. I'm not in charge of binutils, but I could not
see technical obstacles with integrating it into binutils. If it is
useful to users of the GNU binutils, and does not harm if not used,
what could be the problem - apart from licensing?

As more mangling schemes are supported, maybe liberty is the wrong
place for collecting them. Perhaps it is time for a GNU demangler
library?

Regards,
Martin