Re: binutils development (was Re: Problems building binutils-000220 snapshot)

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

   Date: Tue, 22 Feb 2000 09:57:45 -0800
   From: "H . J . Lu" <hjl@lucon.org>

   On Tue, Feb 22, 2000 at 09:28:56AM -0800, H . J . Lu wrote:
   > 
   > > 
   > > Actually, neither dlopen support nor GNAT support has anything to do
   > > with adding --demangler and --style options to the binutils.  Sure,
   > 
   > The whole purpose of --demangler and --style is for dlopen and GNAT.
   > At least, that was what I had in mind when I implemented them.

   BTW, I don't think the current demangler scheme in binutils works very
   well. The problem is the mangling scheme in compiler changes over time.
   I don't think binutils can keep up with it. Instead, each compiler
   should provide its down demangler.so so that binutils can have a chance
   to correctly demangle the mangled symbol. The builtin demangler in
   binutils should be used as the last resort.

The compiler already provides c++filt, so there already is a mechanism
for using an up to date demangler with the binutils: pipe the output
through c++filt.  That is how the linker already works, in fact, when
invoked via the gcc compiler driver.  The builtin demangler is already
the last resort.

Perhaps the bug is adding --demangle options to objdump and nm in the
first place.  They are sometimes convenient, but, as you point out,
they don't always work.

I'm not opposed to adding a shared library interface.  But I see it as
a compiler issue, not a binutils issue.

Ian