binutils development (was Re: Problems building binutils-000220 snapshot)
Ian Lance Taylor
Tue Feb 22 10:06:00 GMT 2000
Date: Tue, 22 Feb 2000 09:57:45 -0800
From: "H . J . Lu" <firstname.lastname@example.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.
More information about the Binutils