From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10024 invoked by alias); 8 May 2002 19:47:53 -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 9788 invoked from network); 8 May 2002 19:47:47 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 8 May 2002 19:47:47 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 175XPe-0008QN-00; Wed, 08 May 2002 15:47:46 -0400 Date: Wed, 08 May 2002 12:47:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: tromey@redhat.com, gdb-patches@sources.redhat.com Subject: Re: Patch: printing java `char' values Message-ID: <20020508194746.GA31548@nevyn.them.org> Mail-Followup-To: Michael Snyder , tromey@redhat.com, gdb-patches@sources.redhat.com References: <877kmh8a6r.fsf@creche.redhat.com> <3CD8429E.DA6D6BC7@redhat.com> <873cx3vdhy.fsf@creche.redhat.com> <3CD9756D.F0AE4AF@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CD9756D.F0AE4AF@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-05/txt/msg00223.txt.bz2 On Wed, May 08, 2002 at 11:58:53AM -0700, Michael Snyder wrote: > Tom Tromey wrote: > > > > >>>>> "Michael" == Michael Snyder 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