Demangling of method names and addr2line/c++filt

Andrew Haley aph@redhat.com
Thu Feb 13 09:09:00 GMT 2003


Ranjit Mathew writes:
 > Hi,
 > 
 >     On my local GCJ 3.3 builds for Win32, class and method names
 > are not being demangled properly while printing out an exception
 > stacktrace.
 > 
 > I have found the problem and have a solution, but I'm not
 > sure if it is valid for other platforms as well. Do tell me if it
 > is, and if not, what could possibly be a better solution.
 > 
 > With GCJ 3.3 on Win32, a method named "foo( )" in a class named
 > "MyEx" gets mangled as "__ZN4MyEx3fooEv" in the final executable.
 > 
 > If one uses "addr2line -f" to get back the symbol (as is done
 > by the GCJ runtime) for the corresponding address, one gets
 > "_ZN4MyEx3fooEv" - note that the leading underscore has been 
 > stripped because on DOS/Win32, all function names (for functions 
 > with the "normal" C calling convention) get emitted out with a
 > leading underscore.
 > 
 > If one then passes this to "c++filt -s java" (again, as is done
 > by the GCJ runtime) one just gets "ZN4MyEx3fooEv" - if however,
 > one uses the "-n" ("do not strip leading underscores") flag
 > to c++filt, one gets the correct output "MyEx.foo()".
 > 
 > I find that Linux does not prefix an underscore to function
 > names like Win32 does and "c++filt -n -s java" still produces
 > the correct output.
 > 
 > What about other platforms like Solaris, Darwin, etc.? Can I
 > blindly add the "-n" flag to c++filt and get the correct 
 > output in all cases?
 > 
 > If yes, I would like to submit a patch for the same. If not,
 > can someone please tell me a better approach that solves the
 > problem?

Addr2line is broken -- it should do whatever is appropriate to the
default naming convention on the platform.  So, if gcc doesn't need a
special flag to make it add underscores, addr2line should be able to
demangle without needing a special flag either.

Andrew.



More information about the Java mailing list