From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27932 invoked by alias); 17 Nov 2005 12:42:22 -0000 Received: (qmail 27913 invoked by uid 22791); 17 Nov 2005 12:42:19 -0000 Received: from fra-del-04.spheriq.net (HELO fra-del-04.spheriq.net) (195.46.51.100) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 12:42:19 +0000 Received: from fra-out-01.spheriq.net (fra-out-01.spheriq.net [195.46.51.129]) by fra-del-04.spheriq.net with ESMTP id jAHCgEEW028629 for ; Thu, 17 Nov 2005 12:42:14 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-01.spheriq.net with ESMTP id jAHCgAIS006499 for ; Thu, 17 Nov 2005 12:42:12 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id jAHCg82K027842 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Nov 2005 12:42:09 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 19897DA46; Thu, 17 Nov 2005 12:42:08 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 26AEF4741B; Thu, 17 Nov 2005 12:45:07 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 52B8C759B5; Thu, 17 Nov 2005 12:45:06 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 236754741B; Thu, 17 Nov 2005 12:44:54 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CGZ44786 (AUTH "andrew stubbs"); Thu, 17 Nov 2005 12:41:54 GMT Message-ID: <437C79F7.9080404@st.com> Date: Thu, 17 Nov 2005 13:46:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Fixup convenience variables on endian switch References: <437B4291.3050006@st.com> <20051117034505.GA3057@nevyn.them.org> In-Reply-To: <20051117034505.GA3057@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.1.07 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00278.txt.bz2 Daniel Jacobowitz wrote: > In addition to Jim's question about structures, and the overall > question of whether this is worth doing... > > On Wed, Nov 16, 2005 at 02:30:41PM +0000, Andrew STUBBS wrote: > >>+ /* Don't do anything if the endian has not changed. >>+ Also disregard FP types because they don't seem to vary with >>+ endian - at least, not on i686 Linux or sparc Solaris. */ > > > That's not correct. The only reason it appears that way is because > those targets normally support only one endian, so their gdbarch system > only selects one set of floatformats. Changing endianness can change > the layout of the standard floating point types arbitrarily. OK, so as it is floats work on x86 Linux, sparc Solaris and any other platform that happens to do it the same way. On other targets the situation is no worse (no different) than it is now. Is there anything I can do to make this better? If there is no definitive way then maintainers/interested parties can always fix it per host as they see the problem. A comment to that effect can certainly go in. As to the struct problem, I admit I had not considered that one. A test for it must go in of course. The problem I am actually trying to solve is that we have addresses and such set up by a script that is sourced before the endian of the target they will be used with is known. It seems like quite a lot of effort to recursively walk through a stuct. This is probably more because I don't know how than anything else. I am sure it is possible. Also, there are unions to consider. These are even harder because the requirement that ints are flipped and floats remain the same (on some hosts) is incompatible. I propose to add a test for struct and union types (bitfields? any others?) and leave them alone. Pointers to these types will continue to work properly of course. Andrew