The implementation of printStackTrace (PrintWriter) in java/lang/Throwable.java has various problems in how it handles symbol demangling: (1) Filtering through an external program is unreliable (though at least there is a backup to print stack trace without demangling). (2) Having a *target* library use a *host* program for filtering is especially wrong. (3) We want Java style demangling for Java methods, but it would be nice to have C++ style demangling for C++ methods. (4) Glibc has (I believe) support for name demangling - it would save space if we could use it. Release: 2.97 20010207 (experimental) Environment: System: Linux kelso.bothner.com 2.4.0-test11 #1 Wed Nov 29 14:11:55 PST 2000 i686 unknown Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: /home/bothner/GNU/gcc/configure --enable-threads=posix --prefix=/home/bothner/GNU/linux --enable-shared --enable-languages=c++,java How-To-Repeat: Look at the code.
Fix: The solution to (1) and (2) these problems is to write a native method that calls cplus_demangle, from the target version of libiberty. We can solve (3) because we can selectively (on a line-by-line bases) decide whether to use Java or C++ style output. This gets a little tricky with CNI native methods: They should be written in Java style, but then how do we distinguish Java and C++ methods - we cannot look at the file extension. Perhaps we really needs some distinction is the mangled name to signfify a Java method. For (4) we need configuration magic to determine if the C library has a compatible cplus_demangle.
This area of code has changed a lot. The demangling portion of the code is now located in gnu/gcj/runtime/NameFinder.java and natNameFinder.cc. It's still done by calling c++filt. Per Bothner's comment regarding (3) still holds as NameFinder is now called one method at a time. The file notes that the lookup method is not thread-safe because of interactions with external processes, which may give an additional incentive to eliminate the external program. This shouldn't be that hard to do, actually, since the native method mentioned by Per obviously goes into natNameFinder.cc in an obvious place.
Now that the demangler part of libsupc++ is now GPL+extension, can we now use it and get rid of the dependency on c++filt?
I think bug 5773 is related.
libgcj does not depend on the C++ libraries, and I am opposed to making it do so. We can perhaps get rid of c++filt, but we can't get rid of addr2line because we need it to get line numbers. A patch has been submitted that removed the neeed for addr2line, but it used libbfd, which is GPL.
How about having libgcj depend on the demangler in libiberty directly? This eliminates the need to invoke c++filt. cp-demangle.c appears to be licensed appropriately (GPL + exception). Is that a reasonable way to go? For addr2line, I see that it is GPL-licensed. Hmm.
I think linking in cp-demangle.c would be appropriate. As I recall that is why it has a libgcj-compatible license. It's just that nobody has done the work...
Fixed. libgcj no longer needs to do symbol demangling.