From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-15130-listarch-gdb-patches=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 1142 invoked by alias); 7 May 2002 21:22:59 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 1128 invoked from network); 7 May 2002 21:22:55 -0000
Received: from unknown (HELO cygnus.com) (205.180.83.203)
  by sources.redhat.com with SMTP; 7 May 2002 21:22:55 -0000
Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA17763;
	Tue, 7 May 2002 14:22:51 -0700 (PDT)
Message-ID: <3CD8429E.DA6D6BC7@redhat.com>
Date: Tue, 07 May 2002 14:22:00 -0000
From: Michael Snyder <msnyder@redhat.com>
Organization: Red Hat, Inc.
X-Accept-Language: en
MIME-Version: 1.0
To: tromey@redhat.com
CC: gdb-patches@sources.redhat.com
Subject: Re: Patch: printing java `char' values
References: <877kmh8a6r.fsf@creche.redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-05/txt/msg00178.txt.bz2

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.

D'oh.  I just remembered -- GDB always labels chars as "TYPE_CODE_INT".
Sorry I didn't think about it earlier.

TYPE_CODE_INT is more of a class than a type.  It includes all 
integer-like types, including char, short, int, long, and long long.

I've no idea what context TYPE_CODE_CHAR might be used in.

Michael

> 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?
> 
> Tom
> 
> public class x
> {
>   public static void main (String[] args)
>   {
>     char c = args[0].charAt(0);
>     System.out.println(c);
>   }
> }
> 
> Index: ChangeLog
> from  Tom Tromey  <tromey@redhat.com>
> 
>         * jv-valprint.c (java_val_print): Add special case for Java char.
> 
> Index: jv-valprint.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/jv-valprint.c,v
> retrieving revision 1.9
> diff -u -r1.9 jv-valprint.c
> --- jv-valprint.c 21 Oct 2001 01:57:42 -0000 1.9
> +++ jv-valprint.c 6 May 2002 17:08:19 -0000
> @@ -451,9 +452,18 @@
>    register unsigned int i = 0; /* Number of characters printed */
>    struct type *target_type;
>    CORE_ADDR addr;
> +  enum type_code code;
> 
>    CHECK_TYPEDEF (type);
> -  switch (TYPE_CODE (type))
> +
> +  /* Sometimes a Java `char' shows up as an `int'.  So here we make a
> +     special case for that.  */
> +  code = TYPE_CODE (type);
> +  if (code == TYPE_CODE_INT && TYPE_LENGTH (type) == 2
> +      && ! strcmp (TYPE_NAME (type), "char"))
> +    code = TYPE_CODE_CHAR;
> +
> +  switch (code)
>      {
>      case TYPE_CODE_PTR:
>        if (format && format != 's')