Re: break jmisc.main

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, Mar 13, 2003 at 12:39:03PM -0800, David Carlton wrote:
> 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.

Yep.

> 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.

Do you know if this actually broke with my caching patch, or if it was
broken before?  I checked, and nowhere in GDB do we ever set the
demangling style to Java.  Not that I could find, at least.

FYI, if you "set demangle-style java" and then "file ./jmisc", this
test passes.  I really don't know what we can do about it.  My
instincts tell me that we need to either:
 - not demangle at all until we know the language; doesn't help for
stabs anyway
 - transform between the Java and C++ demanglings.  Converting from the
C++ output to the Java output looks doable, although exceedingly
annoying:
    - different names for some types (bool vs boolean, char vs wchar_t)
    - All '*' characters are removed
    - JArray<TYPE> becomes TYPE[].
  (That's an exhaustive list.)
  Going the other way, Java -> C++, would probably be impossible
  because of the removed '*'s.
 - Re-demangle if we discover that the symbol is a Java symbol. 
Ewwwwww.

> 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
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer