This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: packing/unpacking 4-octet longs
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Richard dot Earnshaw at arm dot com, twall at oculustech dot com, gdb at sources dot redhat dot com
- Date: Thu, 06 Dec 2001 10:02:38 +0000
- Subject: Re: packing/unpacking 4-octet longs
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
>
> > I'm not aware of this affecting the ARM (except in that FPA format doubles
> > and long doubles always have the word with the exponent at the lowest
> > address, but there's nothing in the IEEE FP specs that says this is
> > invalid). In particular, storing a word, or multi-word, at an unaligned
> > address does not change the order of bytes in memory, so
> > memcpy(unaligned_address, aligned_address, sizeof(some_word))
> > does not require diddling with the internal order (or have I misunderstood
> > the problem?)
>
> That was a useful manual :-) See 5-21 where it explains that a
> misaligned 32bit access gets rotated before it is stored :-/
You're talking about the ARM manual I posted? If so, please read it
again, more carefully. Rotation is *never* done before a store, only on a
load: it's a side effect of the byte-lane steering used for reading bytes;
and it's also useful for fetching half-words from memory on those
machines, since the effect of the rotation means that a ldr (32-bit load)
from a mis-aligned address will always result in the desired bits being
placed in bits 0:15 (little-endian mode) or bits 16:31 (big-endian mode)
of the target register.
Anyway, the issue isn't relevant, since the ARM ABI never makes use of
this behaviour for un-aligned (packed) objects, the memcpy rule I
described above applies.
R.