From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20496 invoked by alias); 13 Mar 2003 20:39:05 -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 20420 invoked from network); 13 Mar 2003 20:39:05 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 13 Mar 2003 20:39:05 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h2DKd3P26308; Thu, 13 Mar 2003 12:39:03 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: gdb Cc: Tom Tromey , Michael Elizabeth Chastain Subject: break jmisc.main From: David Carlton Date: Thu, 13 Mar 2003 20:39:00 -0000 Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-03/txt/msg00211.txt.bz2 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*)". (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