From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13626 invoked by alias); 12 Dec 2003 22:17:12 -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 13619 invoked from network); 12 Dec 2003 22:17:11 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 12 Dec 2003 22:17:11 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id hBCMHB219708 for ; Fri, 12 Dec 2003 17:17:11 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hBCMHA228724; Fri, 12 Dec 2003 17:17:10 -0500 Received: from localhost.localdomain (vpn50-15.rdu.redhat.com [172.16.50.15]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id hBCMH96m024914; Fri, 12 Dec 2003 17:17:09 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id hBCMH4E22540; Fri, 12 Dec 2003 15:17:04 -0700 Date: Fri, 12 Dec 2003 22:17:00 -0000 From: Kevin Buettner Message-Id: <1031212221704.ZM22539@localhost.localdomain> In-Reply-To: Jeff Johnston "[RFC]: remove inconsistency in printcmd.c: print_scalar_formatted" (Dec 12, 3:36pm) References: <3FDA26B1.6010704@redhat.com> To: Jeff Johnston , gdb-patches@sources.redhat.com Subject: Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-12/txt/msg00341.txt.bz2 On Dec 12, 3:36pm, Jeff Johnston wrote: > There's some code in print_scalar_formatted() I would like to remove. > It tests if the sizeof the type of the value being printed is greater > than the sizeof of LONGEST and if so, it may attempt to use > extract_unsigned_integer(). If that fails, it prints out the value in hex. > > There a number of problems with this. First and foremost is the fact > that it is comparing the sizeof with the host's LONGEST type, not the > target. I think this is (sort of) okay. The assumption that's being made is that the space needed to hold the bits on the target will be the same as that on the host. I think gdb has serious problems on host/target combinations where this is untrue. > The second problem is that extract_unsigned_integer() does the > same size test and returns failure so the call is pointless. You mean extract_long_unsigned_integer(), right? When I studied it just now, the call didn't appear to be pointless. It looks to me like the code you're deleting is intended to handle the case where the space needed by a LONGEST isn't large enough to hold the target's type. > The third > problem is that this code creates an inconsistency in how doubles/floats > are treated in comparison to long double. All three of these types > are capable of storing a value greater than that which can be contained > in a LONGEST. At present, floats and possibly doubles will pass the > size test and end up calling unpack_long(). True long double doesn't > pass the test and ends up printing in hex. This problem causes a number > of new errors on ia64 with the latest changes to structs.exp. The new > testcase uses p/c to print out various types and is not ready for the > hex version of the long double value being printed out. I think this is the real problem. The extract_long_unsigned_integer() call attempts to fetch the bits from the type with no conversion (other than leading zero removal if the type is overlong), but, if I'm not mistaken, unpack_long() attempts to do a type conversion and these two approaches to fetching the data definitely yield different kinds of results. > To remedy the problem, I have removed the code. I don't think it is > particularly helpful. I think if the user asks for an integral format, > then they should be prepared to take what that choice entails when > printing a float input. I think you're right. Something that I've wanted from time to time is a way to print the bits comprising a value as some other type. E.g, if I have a float, I'd like to be be able to print the bits that comprise the float as an int (or vice versa). At first, I thought that was the intent of print_scalar_formatted(), but I see now that it's not. If the value is stored in memory, you can do it with the appropriate cast, e.g, if ``val'' is of type float, you can do ``print *(int *)&val'', but AFAIK, you can't do this for values stored in registers or convenience variables. If we had such a mechanism, then I think we'd need some code similar to the chunk that you're deleting. Kevin