binutils development (was Re: Problems building binutils-000220 snapshot)
H . J . Lu
hjl@lucon.org
Tue Feb 22 10:18:00 GMT 2000
More information about the Binutils mailing list
Tue Feb 22 10:18:00 GMT 2000
- Previous message (by thread): binutils development (was Re: Problems building binutils-000220 snapshot)
- Next message (by thread): binutils development (was Re: Problems building binutils-000220 snapshot)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Feb 22, 2000 at 01:05:39PM -0500, Ian Lance Taylor wrote: > 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. > I see. I guess Compaq's C++ compiler takes a different approach which may not involve c++filt. I believe c++filt should be fold into gcc.c. Otherwise, the wrong c++filt may be used when you have more than one C++ compiler installed. I think c++filt should be in binutils and gcc should use something else which is unqiue to each gcc and/or in the same place where cc1plus is. > 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. That is true. > > I'm not opposed to adding a shared library interface. But I see it as > a compiler issue, not a binutils issue. You are right. But sometimes, it is hard to draw the line. H.J.
- Previous message (by thread): binutils development (was Re: Problems building binutils-000220 snapshot)
- Next message (by thread): binutils development (was Re: Problems building binutils-000220 snapshot)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list