This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Patch: printing java `char' values
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-*.