binutils development (was Re: Problems building binutils-000220 snapshot)
Ian Lance Taylor
Tue Feb 22 09:16:00 GMT 2000
Date: Tue, 22 Feb 2000 07:31:12 -0800
From: "H . J . Lu" <firstname.lastname@example.org>
> I have to retract this statement after looking over H.J's current release.
> There's more than just one or two fixes. Some nice features added too:
> --demangler and --style options for various binutils, and --redefine-sym
Just for the record,
1. cplus-dem.c is way out of date. I have pointed it out
many times. I guess many files in libiberty haven't been
updated for a long time.
I just imported the files in libiberty and include from gcc. There
are now only a few differences between the files in the binutils
repository and in the gcc repository.
2. I was told to send my --demangler and --style patch to
the gcc mailing list:
I've explained several times that the cplus-dem.c file in gcc is the
master copy. I don't want divergences in the binutils version. I
think this is a sensible and reasonable position. I have not heard
you explain why it is not.
Since your patch changes cplus-dem.c, it needs to get into the master
source. That is controlled by the gcc maintainers. I am not a gcc
You know as well as I do how to get a patch into gcc. When I look at
the message you cite above, I see you mixing completely unrelated
stuff like some sort of dlopen support with adding GNAT support.
That's a bad start. I even see support for Compaq demangling,
whatever that is, which only works if the user has some sort of .so
file. Do you think that is appropriate for GNU code?
Actually, neither dlopen support nor GNAT support has anything to do
with adding --demangler and --style options to the binutils. Sure,
adding support for demangling GNAT code makes the options more useful.
But the options are meaningful either way. Why not start small, say
with the function which translates strings into demangler parameters?
If that gets into gcc, that should be enough to add the binutils
More information about the Binutils