binutils development (was Re: Problems building binutils-000220 snapshot)
Ian Lance Taylor
Tue Feb 22 09:48:00 GMT 2000
Date: Tue, 22 Feb 2000 09:28:56 -0800
From: "H . J . Lu" <firstname.lastname@example.org>
> 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?
Compaq wants to make their C++ compiler available for Linux/alpha. It
needs that feature in ld. I believe it is appropriate for Linux to
I'm not a gcc maintainer, so it's not my call. But surely Compaq does
not consider their C++ mangling scheme to be a secret. You can't even
keep such a thing a secret. Why don't they just provide the source
for their demangler, so that it can be incorporated into cplus-dem.c?
Adding support for a shared library interface to cplus-dem.c is not
ipso facto bad, but adding one without documentation or support for
adding arbitrary demanglers seems ill-advised. New interfaces should
be defined thoughtfully, not as an ad hoc mechanism tossed into a
patch which is purportedly about something else entirely. Whatever
interface gets put in is one which will have to be supported for a
> 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.
Sure, but those options are just as useful to select, say, Java
demangling, and the Java code is already in cplus-dem.c. Get the
simple stuff in first, and then fight about the complicated stuff.
--demangler is simple. dlopen is complicated. This is basic patch
strategy--you've known it for years.
More information about the Binutils