From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1644 invoked by alias); 19 Jan 2004 22:23:36 -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 1603 invoked from network); 19 Jan 2004 22:23:34 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 19 Jan 2004 22:23:34 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 6F6D78001D2; Mon, 19 Jan 2004 17:23:34 -0500 (EST) Message-ID: <400C58E6.4070908@redhat.com> Date: Mon, 19 Jan 2004 22:23: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 MIME-Version: 1.0 To: "J. Johnston" Cc: Kevin Buettner , gdb-patches@sources.redhat.com, drow@mvista.com Subject: Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted References: <3FDA26B1.6010704@redhat.com> <1031212221704.ZM22539@localhost.localdomain> <3FDA636F.30204@redhat.com> In-Reply-To: <3FDA636F.30204@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00528.txt.bz2 Ping. Could we continue discussing this topic and come to some form of resolution? The new additional ia64 test failures are annoying. -- Jeff J. J. Johnston wrote: > 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. > >