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