Patch: printing java `char' values

Patch: printing java `char' values

[Tom Tromey]

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?

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')

Re: Patch: printing java `char' values

[Michael Snyder]

Hi Tom, 

For future reference, the convention here is that "Patch" means
"I've checked this in, I'm just letting you know".  What you want
is probably "RFC" (request for comment).


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.

I'm not sure why that's happening, but it tickles my familiar-bone.
Has someone else recently posted about something related to this?
Maybe Per Bothner?

> 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?

I agree that this is not the correct fix, but that it
does help illustrate the problem.  Unfortunately, I don't
know who, if anyone, is actively maintaining Java these days.

Anthony?

> 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')

Re: Patch: printing java `char' values

[Tom Tromey]

>>>>> "Michael" == Michael Snyder <msnyder@redhat.com> writes:

Michael> For future reference, the convention here is that "Patch"
Michael> means "I've checked this in, I'm just letting you know".
Michael> What you want is probably "RFC" (request for comment).

Thanks.

Michael> I'm not sure why that's happening, but it tickles my
Michael> familiar-bone.  Has someone else recently posted about
Michael> something related to this?  Maybe Per Bothner?

I don't remember seeing anything about it, but then I only skim this
list.

>> 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?

Michael> I agree that this is not the correct fix, but that it
Michael> does help illustrate the problem.  Unfortunately, I don't
Michael> know who, if anyone, is actively maintaining Java these days.

Nobody.  I've spent a little time this week looking into the major
Java annoyances (meaning: stuff that worked once but now doesn't) as
time permits.  Unfortunately my gdb time and knowledge are both
limited.  I was hoping someone would understand where the type comes
from in this situation, so I could see if a more appropriate fix is
available.

Tom

Re: Patch: printing java `char' values

[Daniel Jacobowitz]

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

Re: Patch: printing java `char' values

[Michael Snyder]

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')

Re: Patch: printing java `char' values

[Tom Tromey]

>>>>> "Michael" == Michael Snyder <msnyder@redhat.com> writes:

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

Don't worry -- I'm just happy anybody read the patch.

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

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

Ok.  Does this mean my patch is ok?  Or is there something better way
to do it?


BTW, if you know about types in gdb, I also sent another Java type
related patch last week.  Again, to me it looked like a hack, but I
don't really understand what is going on.

Thanks,
Tom

Re: Patch: printing java `char' values

[Andrew Cagney]

> 
> Michael> I agree that this is not the correct fix, but that it
> Michael> does help illustrate the problem.  Unfortunately, I don't
> Michael> know who, if anyone, is actively maintaining Java these days.
> 
> Nobody.  I've spent a little time this week looking into the major
> Java annoyances (meaning: stuff that worked once but now doesn't) as
> time permits.  Unfortunately my gdb time and knowledge are both
> limited.  I was hoping someone would understand where the type comes
> from in this situation, so I could see if a more appropriate fix is
> available.

FYI, Per or Anthony.

enjoy,
Andrew

Re: Patch: printing java `char' values

[Michael Snyder]

Tom Tromey wrote:
> 
> >>>>> "Michael" == Michael Snyder <msnyder@redhat.com> writes:
> 
> Michael> D'oh.  I just remembered -- GDB always labels chars as
> Michael> "TYPE_CODE_INT".  Sorry I didn't think about it earlier.
> 
> Don't worry -- I'm just happy anybody read the patch.
> 
> Michael> TYPE_CODE_INT is more of a class than a type.  It includes
> Michael> all integer-like types, including char, short, int, long, and
> Michael> long long.
> 
> Michael> I've no idea what context TYPE_CODE_CHAR might be used in.
> 
> Ok.  Does this mean my patch is ok?  Or is there something better way
> to do it?

Hmmm, looking at it now.

I see that none of the symbol readers except for stabsread.c will ever
create a TYPE_CODE_CHAR node.  And stabs does it only in a special 
circumstance (and only for the RS/6000).  So you're unlikely to get
symbol info that says that your variable is a TYPE_CODE_CHAR.
That's probably why you're seeing it as TYPE_CODE_INT (which in my
experience is normal).

I recommend that you emulate what C does, and whenever you have a
TYPE_CODE_INT whose length is the length of a char (which for Java
appears to be two bytes), you look at the type_name and see if it is
"char" -- in which case you print it as a char.  Umm, which appears
to be exactly what you're doing -- except that I'd be inclined to 
put the test within the 
	case TYPE_CODE_INT:
block, rather than meddle with state before the switch statement.
That appears to be what the other language modules do.

Michael

Re: Patch: printing java `char' values

[Daniel Jacobowitz]

On Wed, May 08, 2002 at 11:58:53AM -0700, Michael Snyder wrote:
> Tom Tromey wrote:
> > 
> > >>>>> "Michael" == Michael Snyder <msnyder@redhat.com> writes:
> > 
> > Michael> D'oh.  I just remembered -- GDB always labels chars as
> > Michael> "TYPE_CODE_INT".  Sorry I didn't think about it earlier.
> > 
> > Don't worry -- I'm just happy anybody read the patch.
> > 
> > Michael> TYPE_CODE_INT is more of a class than a type.  It includes
> > Michael> all integer-like types, including char, short, int, long, and
> > Michael> long long.
> > 
> > Michael> I've no idea what context TYPE_CODE_CHAR might be used in.
> > 
> > Ok.  Does this mean my patch is ok?  Or is there something better way
> > to do it?
> 
> Hmmm, looking at it now.
> 
> I see that none of the symbol readers except for stabsread.c will ever
> create a TYPE_CODE_CHAR node.  And stabs does it only in a special 
> circumstance (and only for the RS/6000).  So you're unlikely to get
> symbol info that says that your variable is a TYPE_CODE_CHAR.
> That's probably why you're seeing it as TYPE_CODE_INT (which in my
> experience is normal).

Seems that way...

> I recommend that you emulate what C does, and whenever you have a
> TYPE_CODE_INT whose length is the length of a char (which for Java
> appears to be two bytes), you look at the type_name and see if it is
> "char" -- in which case you print it as a char.  Umm, which appears
> to be exactly what you're doing -- except that I'd be inclined to 
> put the test within the 
> 	case TYPE_CODE_INT:
> block, rather than meddle with state before the switch statement.
> That appears to be what the other language modules do.

Soemthing interesting is going on here... I'd like to know how it
works in the stabs case.  Tom, could you compile your test with
-gstabs+ and step through the char printing code?  When I do that,
'c' has TYPE_CODE_CHAR set anyway, even though the stabs reader marked
it as TYPE_CODE_INT.  It'd be nice to figure out where that magic
happens.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Patch: printing java `char' values

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

Daniel> Soemthing interesting is going on here... I'd like to know how
Daniel> it works in the stabs case.  Tom, could you compile your test
Daniel> with -gstabs+ and step through the char printing code?  When I
Daniel> do that, 'c' has TYPE_CODE_CHAR set anyway, even though the
Daniel> stabs reader marked it as TYPE_CODE_INT.  It'd be nice to
Daniel> figure out where that magic happens.

When I use -gstabs+ the type looks like this:

    (gdb) p *type
    $1 = {
      code = TYPE_CODE_CHAR, 
      name = 0x83e6574 "char", 
      tag_name = 0x0, 
      length = 2, 
      upper_bound_type = 0, 
      lower_bound_type = 0, 
      objfile = 0x0, 
      target_type = 0x0, 
      pointer_type = 0x0, 
      reference_type = 0x0, 
      cv_type = 0x83d4980, 
      as_type = 0x83d4980, 
      flags = 1, 
      nfields = 0, 
      fields = 0x0, 
      vptr_basetype = 0x0, 
      vptr_fieldno = -1, 
      type_specific = {
	arg_types = 0x0, 
	cplus_stuff = 0x0, 
	floatformat = 0x0
      }
    }

HTH,
Tom

Re: Patch: printing java `char' values

[Daniel Jacobowitz]

On Wed, May 08, 2002 at 02:42:16PM -0600, Tom Tromey wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> Daniel> Soemthing interesting is going on here... I'd like to know how
> Daniel> it works in the stabs case.  Tom, could you compile your test
> Daniel> with -gstabs+ and step through the char printing code?  When I
> Daniel> do that, 'c' has TYPE_CODE_CHAR set anyway, even though the
> Daniel> stabs reader marked it as TYPE_CODE_INT.  It'd be nice to
> Daniel> figure out where that magic happens.
> 
> When I use -gstabs+ the type looks like this:
> 
>     (gdb) p *type
>     $1 = {
>       code = TYPE_CODE_CHAR, 
>       name = 0x83e6574 "char", 

Yes, exactly.  I'd like to figure out where that comes from.

... got it.  Again, there are two definitions of char in the object
file:

4      LSYM   0      0      00000000 112    char:t(0,2)=r(0,2);0;127;
37     LSYM   0      0      00000000 1088   char:t(0,2)=@s16;-20;

See that -20?  That's the supposedly rs6000-only (that function is no
longer accurately named) character type.  Amusingly, both of those have
a size of one.  Aren't java 'char' variables bigger than that?  Another
debug info problem.

>       length = 2, 

Hmm, looks like the length got corrected somehow.

So, the debug info needs to be fixed to only emit the builtin types
once; and then either GDB needs to decide to represent DWARF-2 char
types as TYPE_CODE_CHAR also, or to support TYPE_CODE_INT characters
in Java code.  I've no idea which decision is better.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Patch: printing java `char' values

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Wed, May 08, 2002 at 02:42:16PM -0600, Tom Tromey wrote:
> > >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> >
> > Daniel> Soemthing interesting is going on here... I'd like to know how
> > Daniel> it works in the stabs case.  Tom, could you compile your test
> > Daniel> with -gstabs+ and step through the char printing code?  When I
> > Daniel> do that, 'c' has TYPE_CODE_CHAR set anyway, even though the
> > Daniel> stabs reader marked it as TYPE_CODE_INT.  It'd be nice to
> > Daniel> figure out where that magic happens.
> >
> > When I use -gstabs+ the type looks like this:
> >
> >     (gdb) p *type
> >     $1 = {
> >       code = TYPE_CODE_CHAR,
> >       name = 0x83e6574 "char",
> 
> Yes, exactly.  I'd like to figure out where that comes from.
> 
> ... got it.  Again, there are two definitions of char in the object
> file:
> 
> 4      LSYM   0      0      00000000 112    char:t(0,2)=r(0,2);0;127;
> 37     LSYM   0      0      00000000 1088   char:t(0,2)=@s16;-20;
> 
> See that -20?  That's the supposedly rs6000-only (that function is no
> longer accurately named) character type.  Amusingly, both of those have
> a size of one.  Aren't java 'char' variables bigger than that?  Another
> debug info problem.
> 
> >       length = 2,
> 
> Hmm, looks like the length got corrected somehow.
> 
> So, the debug info needs to be fixed to only emit the builtin types
> once; and then either GDB needs to decide to represent DWARF-2 char
> types as TYPE_CODE_CHAR also, or to support TYPE_CODE_INT characters
> in Java code.  I've no idea which decision is better.

I'd prefer not to perpetuate TYPE_CODE_CHAR.  This seems to have been
a one-time thing, and not (I think) a good idea.  In general if GDB
wants to know if two things can be added or XOR'd or something, it 
only needs to check to see if they are TYPE_CODE_INT, (because chars
are really ints of size 1).  This should have been implemented as a
TYPE_FLAG_*, not a TYPE_CODE-*.

Re: Patch: printing java `char' values

[Daniel Jacobowitz]

On Wed, May 08, 2002 at 01:57:21PM -0700, Michael Snyder wrote:
> I'd prefer not to perpetuate TYPE_CODE_CHAR.  This seems to have been
> a one-time thing, and not (I think) a good idea.  In general if GDB
> wants to know if two things can be added or XOR'd or something, it 
> only needs to check to see if they are TYPE_CODE_INT, (because chars
> are really ints of size 1).  This should have been implemented as a
> TYPE_FLAG_*, not a TYPE_CODE-*.

Sounds good to me.  Would you be interested in patches which actually
change TYPE_CODE_CHAR to TYPE_FLAG_CHAR, if it's practical?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Patch: printing java `char' values

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Wed, May 08, 2002 at 01:57:21PM -0700, Michael Snyder wrote:
> > I'd prefer not to perpetuate TYPE_CODE_CHAR.  This seems to have been
> > a one-time thing, and not (I think) a good idea.  In general if GDB
> > wants to know if two things can be added or XOR'd or something, it
> > only needs to check to see if they are TYPE_CODE_INT, (because chars
> > are really ints of size 1).  This should have been implemented as a
> > TYPE_FLAG_*, not a TYPE_CODE-*.
> 
> Sounds good to me.  Would you be interested in patches which actually
> change TYPE_CODE_CHAR to TYPE_FLAG_CHAR, if it's practical?

Uhh, sure.  That would be a non-trivial change, and it might take
a little effort to verify that it was transparent... but I think
the idea is good (quite apart from the fact that I thought of it <g>)

Re: Patch: printing java `char' values

[Tom Tromey]

>>>>> "Michael" == Michael Snyder <msnyder@redhat.com> writes:

Michael> I recommend that you emulate what C does, and whenever you
Michael> have a TYPE_CODE_INT whose length is the length of a char
Michael> (which for Java appears to be two bytes), you look at the
Michael> type_name and see if it is "char" -- in which case you print
Michael> it as a char.

How does this look?

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	* jv-valprint.c (java_val_print): Handle `char' as a special case
	of TYPE_CODE_INT.

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 8 May 2002 22:41:22 -0000
@@ -497,20 +499,21 @@
       return i;
 
     case TYPE_CODE_CHAR:
-      format = format ? format : output_format;
-      if (format)
-	print_scalar_formatted (valaddr, type, format, 0, stream);
-      else
-	LA_PRINT_CHAR ((int) unpack_long (type, valaddr), stream);
-      break;
-
     case TYPE_CODE_INT:
       /* Can't just call c_val_print because that print bytes as C chars. */
       format = format ? format : output_format;
       if (format)
 	print_scalar_formatted (valaddr, type, format, 0, stream);
       else
-	val_print_type_code_int (type, valaddr, stream);
+	{
+	  enum type_code code = TYPE_CODE (type);
+	  if (code == TYPE_CODE_CHAR
+	      || (code == TYPE_CODE_INT && TYPE_LENGTH (type) == 2
+		  && ! strcmp (TYPE_NAME (type), "char")))
+	    LA_PRINT_CHAR ((int) unpack_long (type, valaddr), stream);
+	  else
+	    val_print_type_code_int (type, valaddr, stream);
+	}
       break;
 
     case TYPE_CODE_STRUCT:

Re: Patch: printing java `char' values

[Michael Snyder]

Tom Tromey wrote:
> 
> >>>>> "Michael" == Michael Snyder <msnyder@redhat.com> writes:
> 
> Michael> I recommend that you emulate what C does, and whenever you
> Michael> have a TYPE_CODE_INT whose length is the length of a char
> Michael> (which for Java appears to be two bytes), you look at the
> Michael> type_name and see if it is "char" -- in which case you print
> Michael> it as a char.
> 
> How does this look?

Yes, that's the idea.  I wouldn't even bother with the temp variable--
I would just call TYPE_CODE (type) twice.  It's a macro, and not
expensive to evaluate.  Then you don't need the brackets.

> 
> Index: ChangeLog
> from  Tom Tromey  <tromey@redhat.com>
> 
>         * jv-valprint.c (java_val_print): Handle `char' as a special case
>         of TYPE_CODE_INT.
> 
> 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 8 May 2002 22:41:22 -0000
> @@ -497,20 +499,21 @@
>        return i;
> 
>      case TYPE_CODE_CHAR:
> -      format = format ? format : output_format;
> -      if (format)
> -       print_scalar_formatted (valaddr, type, format, 0, stream);
> -      else
> -       LA_PRINT_CHAR ((int) unpack_long (type, valaddr), stream);
> -      break;
> -
>      case TYPE_CODE_INT:
>        /* Can't just call c_val_print because that print bytes as C chars. */
>        format = format ? format : output_format;
>        if (format)
>         print_scalar_formatted (valaddr, type, format, 0, stream);
>        else
> -       val_print_type_code_int (type, valaddr, stream);
> +       {
> +         enum type_code code = TYPE_CODE (type);
> +         if (code == TYPE_CODE_CHAR
> +             || (code == TYPE_CODE_INT && TYPE_LENGTH (type) == 2
> +                 && ! strcmp (TYPE_NAME (type), "char")))
> +           LA_PRINT_CHAR ((int) unpack_long (type, valaddr), stream);
> +         else
> +           val_print_type_code_int (type, valaddr, stream);
> +       }
>        break;
> 
>      case TYPE_CODE_STRUCT:

Re: Patch: printing java `char' values

[Tom Tromey]

>>>>> "Michael" == Michael Snyder <msnyder@redhat.com> writes:

Michael> Yes, that's the idea.  I wouldn't even bother with the temp
Michael> variable-- I would just call TYPE_CODE (type) twice.  It's a
Michael> macro, and not expensive to evaluate.  Then you don't need
Michael> the brackets.

Ok.  I've made this change and another one suggested by Andrew Cagney
privately.

Is this one ok to commit?

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	* jv-valprint.c (java_val_print): Handle `char' as a special case
	of TYPE_CODE_INT.

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 9 May 2002 04:05:49 -0000
@@ -497,18 +498,17 @@
       return i;
 
     case TYPE_CODE_CHAR:
-      format = format ? format : output_format;
-      if (format)
-	print_scalar_formatted (valaddr, type, format, 0, stream);
-      else
-	LA_PRINT_CHAR ((int) unpack_long (type, valaddr), stream);
-      break;
-
     case TYPE_CODE_INT:
-      /* Can't just call c_val_print because that print bytes as C chars. */
+      /* Can't just call c_val_print because that prints bytes as C
+	 chars.  */
       format = format ? format : output_format;
       if (format)
 	print_scalar_formatted (valaddr, type, format, 0, stream);
+      else if (TYPE_CODE (type) == TYPE_CODE_CHAR
+	       || (TYPE_CODE (type) == TYPE_CODE_INT
+		   && TYPE_LENGTH (type) == 2
+		   && strcmp (TYPE_NAME (type), "char") == 0))
+	LA_PRINT_CHAR ((int) unpack_long (type, valaddr), stream);
       else
 	val_print_type_code_int (type, valaddr, stream);
       break;

Re: Patch: printing java `char' values

[Michael Snyder]

Tom Tromey wrote:
> 
> >>>>> "Michael" == Michael Snyder <msnyder@redhat.com> writes:
> 
> Michael> Yes, that's the idea.  I wouldn't even bother with the temp
> Michael> variable-- I would just call TYPE_CODE (type) twice.  It's a
> Michael> macro, and not expensive to evaluate.  Then you don't need
> Michael> the brackets.
> 
> Ok.  I've made this change and another one suggested by Andrew Cagney
> privately.
> 
> Is this one ok to commit?
> 
> Tom

Looks good -- commit away.

> 
> Index: ChangeLog
> from  Tom Tromey  <tromey@redhat.com>
> 
>         * jv-valprint.c (java_val_print): Handle `char' as a special case
>         of TYPE_CODE_INT.
> 
> 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 9 May 2002 04:05:49 -0000
> @@ -497,18 +498,17 @@
>        return i;
> 
>      case TYPE_CODE_CHAR:
> -      format = format ? format : output_format;
> -      if (format)
> -       print_scalar_formatted (valaddr, type, format, 0, stream);
> -      else
> -       LA_PRINT_CHAR ((int) unpack_long (type, valaddr), stream);
> -      break;
> -
>      case TYPE_CODE_INT:
> -      /* Can't just call c_val_print because that print bytes as C chars. */
> +      /* Can't just call c_val_print because that prints bytes as C
> +        chars.  */
>        format = format ? format : output_format;
>        if (format)
>         print_scalar_formatted (valaddr, type, format, 0, stream);
> +      else if (TYPE_CODE (type) == TYPE_CODE_CHAR
> +              || (TYPE_CODE (type) == TYPE_CODE_INT
> +                  && TYPE_LENGTH (type) == 2
> +                  && strcmp (TYPE_NAME (type), "char") == 0))
> +       LA_PRINT_CHAR ((int) unpack_long (type, valaddr), stream);
>        else
>         val_print_type_code_int (type, valaddr, stream);
>        break;