From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27540 invoked by alias); 5 Dec 2001 16:26:07 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27505 invoked from network); 5 Dec 2001 16:26:02 -0000 Received: from unknown (HELO localhost.cygnus.com) (24.114.42.213) by sources.redhat.com with SMTP; 5 Dec 2001 16:26:02 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 602443E29; Wed, 5 Dec 2001 11:25:58 -0500 (EST) Message-ID: <3C0E4A96.6070601@cygnus.com> Date: Wed, 05 Dec 2001 08:26:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.3) Gecko/20011020 X-Accept-Language: en-us MIME-Version: 1.0 To: twall@oculustech.com Cc: gdb@sources.redhat.com Subject: Re: packing/unpacking 4-octet longs References: <3C0CD32D.A118C5A0@oculustech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00033.txt.bz2 The short unhelpful answer is: yes, you have a problem. As you note, GDB very much assumes that bytes laid out in the ``struct value *'' are identical to those that appear in memory. > I'm working on a DSP port (yes, I'm the one tossing the OCTETS_PER_BYTE > strangeness about) and TI has introduced yet another Really Strange Thing. > > Longs on this chip are packed little-endian. No wait, they're packed > big-endian. No-wait, it's both! > > Basically, words are packed little-endian w/r/t octets, but the two words are > big-endian, e.g. > > 0xaabbccdd is stored as 0xbb 0xaa 0xdd 0xcc. This I can account for in the > long/float/double packing/unpacking routines (though I'm not sure how I'm > going to make a clean patch yet...). The problem is that the word order > switches if the value is accessed at an odd address (apparently this made > sense to the hardware designers). The MS word of a long is always the first > one accessed (they must have forgotten that the chip was little-endian). Mutter something about hardware engineers taking short cuts :-) I'm pretty sure that there is another very old wacko architecture that did something similar to this, I'm trying to remember which. pdp11? original m68k? This problem also shows up on hardware that implemented big/little endian using xor bits - Arm? I think, gdb has avoided this issue by documenting it as a feature :-/ Regarding the easy case, the thing on the things to do today list is to add byte order information to the integer version of ``struct type''. That way, just like for the floating-point types, the type and not the target determins how the bytes are unpacked. Regarding the hard case, when you say that the byte order switches at an odd address. Is this an odd word address or an odd byte address? > Any ideas of how to make this happen? I remember doing a fix for something > similar way back, but looking at the code now, by the time the data is > packed/unpacked, the target address is long gone. I doubt I can reliably do > swapping every time I access a 4-octet block of target data. > >