break jmisc.main

[David Carlton <carlton@math.stanford.edu>]

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