break jmisc.main

David Carlton
2003-03-13T20:39:05Z

Here's the scoop with the FAILs on "break jmisc.main" and "break
jmisc.main(java.lang.String[]))".

1) For "break jmisc.main", decode_line_1 calls decode_compound (which
handles C++ and Java compound data structures). That notices that
there is a class calles 'jmisc', and then looks for a member in it
called 'main'.

Unfortunately, GDB thinks the member in question is called
'jmisc.main(java.lang.String[])' instead of just 'main': the debug
info says:

.long .LC2 # DW_AT_name: "jmisc.main(java.lang.String[])"

Sigh. GCJ should get fixed.

2) For "break jmisc.main(java.lang.String[])", decode_compound gets
bypassed, and decode_variable gets called, looking for a symbol of
that name. Unfortunately, it doesn't find one: the symbol that it
finds is called something strange like
"jmisc::main(Jaray<java::lang::String*>*)". (I'm pretty sure
that's right, though I'd have to check this at home to be sure;
that's what c++filt demangles the name to.)

Something weird is going on here; at first, I'd assumed this was a
bug in cplus_demangle, but c++filt -s java gets the name demangled
correctly. So my guess is that, somewhere, a demangler is getting
called in a situation where the symbol isn't yet identified as a
Java symbol, so the C++ demangler gets used. Do the minsym readers
reliably know the language of the minsyms they're creating? If
not, then we could be getting the bad value there and caching it
with the new demangling code, so the bad value remains when the
symbol table is setting the symbol's name.

So, we have two things to do: submit a bug report to the GCJ people,
and track down where the symbol name is getting demangled
incorrectly. (And a third thing: convince somebody who knows more
about GCJ to become GDB's Java maintainer.)

David Carlton
carlton@math.stanford.edu