From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22396 invoked by alias); 13 Mar 2003 20:57:02 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 22388 invoked from network); 13 Mar 2003 20:57:01 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 13 Mar 2003 20:57:01 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18tbeB-0007uW-00; Thu, 13 Mar 2003 16:57:59 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18tZkl-0004k4-00; Thu, 13 Mar 2003 15:56:39 -0500 Date: Thu, 13 Mar 2003 20:57:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: gdb , Tom Tromey , Michael Elizabeth Chastain Subject: Re: break jmisc.main Message-ID: <20030313205639.GA18052@nevyn.them.org> Mail-Followup-To: David Carlton , gdb , Tom Tromey , Michael Elizabeth Chastain References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00213.txt.bz2 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*)". (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 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