Get rid of underscore.c
Nick Clifton
nickc@redhat.com
Mon Sep 23 08:34:00 GMT 2002
More information about the Binutils mailing list
Mon Sep 23 08:34:00 GMT 2002
- Previous message (by thread): Get rid of underscore.c
- Next message (by thread): Get rid of underscore.c
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): Get rid of underscore.c
- Next message (by thread): Get rid of underscore.c
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list