Re: Demangler update?

[Ian Lance Taylor <ian at zembu dot com>]

   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