From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4800 invoked by alias); 8 May 2002 21:10:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4790 invoked from network); 8 May 2002 21:10:38 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 8 May 2002 21:10:38 -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 OAA25734; Wed, 8 May 2002 14:10:26 -0700 (PDT) Message-ID: <3CD99131.76E0B9BB@redhat.com> Date: Wed, 08 May 2002 14:10:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Tom Tromey , gdb-patches@sources.redhat.com Subject: Re: Patch: printing java `char' values References: <877kmh8a6r.fsf@creche.redhat.com> <3CD8429E.DA6D6BC7@redhat.com> <873cx3vdhy.fsf@creche.redhat.com> <3CD9756D.F0AE4AF@redhat.com> <20020508194746.GA31548@nevyn.them.org> <878z6umkwn.fsf@creche.redhat.com> <20020508204626.GA2093@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00232.txt.bz2 Daniel Jacobowitz wrote: > > On Wed, May 08, 2002 at 02:42:16PM -0600, Tom Tromey wrote: > > >>>>> "Daniel" == Daniel Jacobowitz 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-*.