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>, 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 16:07:00 -0500
- Subject: Re: break jmisc.main
- References: <ro1el5bknmg.fsf@jackfruit.Stanford.EDU> <20030313205639.GA18052@nevyn.them.org>
On Thu, Mar 13, 2003 at 03:56:39PM -0500, Daniel Jacobowitz wrote:
> 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.
Never mind, I've found where it happened; there was an explicit
DMGL_JAVA.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer