From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13214 invoked by alias); 7 May 2002 20:43:35 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13150 invoked from network); 7 May 2002 20:43:34 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 7 May 2002 20:43:34 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 175Bo6-0007zB-00 for ; Tue, 07 May 2002 16:43:34 -0400 Date: Tue, 07 May 2002 13:43:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: Patch: printing java `char' values Message-ID: <20020507204334.GA30186@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <877kmh8a6r.fsf@creche.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877kmh8a6r.fsf@creche.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-05/txt/msg00177.txt.bz2 On Mon, May 06, 2002 at 11:20:44AM -0600, Tom Tromey wrote: > Compile the appended java program with `gcj -g'. Run gdb on it, and > run it with the argument "abc". Put a breakpoint on main and step > past the assignment. Then do `p c'. > > I get: > > (gdb) p c > $1 = 97 > > This is wrong. Debugging gdb a little, I found that in java_val_print > we are seeint a TYPE_CODE_INT and not a TYPE_CODE_CHAR. > > The appended hack fixes the problem for me. I'm sure there is some > better way to handle this, but I don't know what. Why would I end up > with a TYPE_CODE_INT here? Hmm... $2 = {code = TYPE_CODE_INT, name = 0x82eeb88 "char", tag_name = 0x0, ... So there is a created type named "char" with TYPE_CODE_INT. Where does it come from? It comes from the DWARF-2: the DW_TAG_base_type entry for "char" appears twice, once marked as "signed" and once as "unsigned char". "signed" is an integer. You've gotta figure out where that's coming from. It sounds like it might be worthwhile to spend some time reading over gcj's DWARF-2 output and trying to figure out where some of the oddities come from. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer