Re: Patch: printing java `char' values

[Michael Snyder <msnyder@redhat.com>]

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-*.