From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1243 invoked by alias); 13 Dec 2003 00:55:13 -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 1236 invoked from network); 13 Dec 2003 00:55:12 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 13 Dec 2003 00:55:12 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 22CCB80018E; Fri, 12 Dec 2003 19:55:12 -0500 (EST) Message-ID: <3FDA636F.30204@redhat.com> Date: Sat, 13 Dec 2003 00:55:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted References: <3FDA26B1.6010704@redhat.com> <1031212221704.ZM22539@localhost.localdomain> In-Reply-To: <1031212221704.ZM22539@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00345.txt.bz2 Kevin Buettner wrote: > 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. > Yes, sorry about the name typo. The extract_long_unsigned_integer() function ends up testing the type_size - leading zeroes vs the sizeof(LONGEST). For most floats this will fail because of the biased exponent so it returns false. if (len <= (int) sizeof (LONGEST)) { *pval = (LONGEST) extract_unsigned_integer (first_addr, sizeof (LONGEST)); return 1; } return 0; } > >>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. > I suppose new format specifiers could always be added in the future to do just what you want. -- Jeff J.