This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: break jmisc.main
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: David Carlton <carlton at math dot stanford dot edu>
- Cc: gdb <gdb at sources dot redhat dot com>, Tom Tromey <tromey at redhat dot com>,Michael Elizabeth Chastain <mec at shout dot net>
- Date: Thu, 13 Mar 2003 15:56:39 -0500
- Subject: Re: break jmisc.main
- References: <ro1el5bknmg.fsf@jackfruit.Stanford.EDU>
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 at math dot stanford dot edu
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer