Re: Demangler update?

[Ken Block USG <block at zk3 dot dec dot com>]

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?
begin:vcard 
n:Block;Kenneth
x-mozilla-html:FALSE
org:CTG C/C++ Compiler
version:2.1
email;internet:block@zk3.dec.com
adr;quoted-printable:;;110 Spit Brook Road=0D=0AM/S ZKO3-2/W02;Nashua;NH;03062;USA
x-mozilla-cpt:;0
tel;work:603-884-2819
fn:Kenneth Block
end:vcard