This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Demangler update?


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]