On Aug 2, 2005, at 10:32 AM, Shaun Jackman wrote:
In a typical Ethernet/IP ARP header the source IP address is
unaligned. Instead of using...
out->srcIPAddr = in->dstIPAddr;
... I used...
memcpy(&out->srcIPAddr, &in->dstIPAddr, sizeof(uint32_t));
... to account for the unaligned destination. This worked until gcc 4,
which now generates a simple load/store.
ldr r3, [r6, #24]
adds r2, r4, #0
adds r2, #14
str r3, [r2, #0]
A nice optimisation, but in this case it's incorrect. $r4 is aligned,
and the result of adding #14 to $r4 is an unaligned pointer.
Should gcc know better, or do I need to give it a little more
information to help it out?
gcc-help is the correct list to ask this question on. Anyway, I
suspect people would be aided in helping you by seeing the source
code and knowing what version of gcc you're using... I suspect you
don't mark the structure as packed and as using 1 or 2 byte
alignment. If you do that, then the compiler should generate the
correct code, for example:
mrs $ cat t1.c
struct {
char a[14];
int i __attribute__((aligned(1), packed));
} s, d;
main() {
d.i = s.i;
}
$ arm-gcc -O4 t1.c -S
gives:
_main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
str sl, [sp, #-4]!
ldr sl, .L3
ldr r2, .L3+4
.L2:
add sl, pc, sl
ldr ip, [sl, r2]
ldr r0, .L3+8
ldrh r1, [ip, #16]
ldr r2, [sl, r0]
ldrh r3, [ip, #14]
@ lr needed for prologue
strh r1, [r2, #16] @ movhi
strh r3, [r2, #14] @ movhi
ldmfd sp!, {sl}
mov pc, lr
for me. Notice the adding of 14, notice the two 16 bit moves instead
of one 4 byte move. If you lie to the compiler, it will make your
life rough. Telling it that it is aligned, when the data isn't
aligned, is a lie.
