This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Get rid of underscore.c


Hi Guys,

: Andrew Cagney wrote:
:
: How about GCC bundle in a program called g++filt while binutils
: bundle c++filt.

I like this idea.  We keep the demangling code in one place -
libiberty - where it can be accessed by all the tools that want to use
it (g++, gdb, binutils, libstdc++), and each tool can decide how it
wants to interface to this code.  G++ would have its g++filt program,
binutils would have c++filt, libstdc++ would do whatever it does with
it and so on.

The only problem I see with this solution is user confusion.  If they
install both gcc and binutils they will end up with two demangler
programs in their bin.  Which one do they use ?  Provided that they
both produce the same results it will not matter which one they
choose, but if the results differ things could get really confusing.

[We could do some sneaky things like have the binutils c++filt check to
see if there is a g++filt available in the same directory, and if so
run that instead of running itself, or maybe issue a warning message
instead.]

Provided that we have clear documentation of this "feature" of
combining the two project installations, I think that we should be OK.


> Jason Merrill <jason@redhat.com> writes:
> 
> I honestly don't see a reason for binutils to build c++filt.  Do
> you?  I'm not being sarcastic.

One reason is to support the debugging of binaries produced by non-gcc
compilers.  Although you are correct in saying that most compilers do
provide their own demangler, that demangler may not be free.  One of
the goals of the binutils project is to provide a free, alternative,
set of binary tools that anyone can use, regardless of the compiler/
object-code-producer that they are using.
 
> If you really want to build it in binutils, I suppose we can work
> something out, just please don't remove it from gcc.

Agreed.  We understand how having it in GCC will make your life easier
(and other G++ developers).  We are just trying to resolve whether an
alternative version should be kept in binutils, or whether now is the
time for binutils to give up this tool.  The majority of opinions that
I have seen expressed so far have been for keeping (a version of) the
tool in binutils.

Cheers
        Nick


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]