Re: packing/unpacking 4-octet longs

[Andrew Cagney <ac131313@cygnus.com>]

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.
> 
>