Re: Patch: printing java `char' values

[Daniel Jacobowitz <drow@mvista.com>]

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