On Tue, 18 Jan 2011 15:40:40 -0500 Michael Jerris <mike@jerris.com> wrote:
On Jan 18, 2011, at 2:42 PM, M D wrote:
On Tue, 18 Jan 2011 12:54:53 -0500 Michael Jerris <mike@jerris.com> wrote:
In general, should I conclude that this issue has not been encountered before?
This has certainly been encountered before, on different platforms, including arm. I suspect this is a toolchain issue more than anything in this case as we have worked on arm for quite some time.
Sorry for the noise. Looks like a gcc-4.3 issue. I have tested the following code with gcc-4.3.3, gcc-4.3.5 and gcc-4.4.4 and gcc-4.4.5. gcc-4.4.4 comes from gentoo crossdev environment, everything else is from openwrt build system. The 4.4 versions align the buf2 in the code below with the 32-bit boundary while the 4.3 versions don't. All test cases compiled with -march=armv5te. No other compiler flags/switches used. Optimization options -Os vs -O2 do not seem to make a difference. If anyone has ready access to arm-gcc and an arm machine, I would be curious to see my experience is consistent with others'. cheers, -m P.S Code from memory. ----- test_align.c ---- #include<stdio.h> #include<stdlib.h> #include <string.h> #include<netinet/in.h> /* typedef struct { uint16_t type; uint16_t length; char id[16]; } switch_stun_packet_header_t; */ void main(void) { uint8_t buf1[260] = {0}; char j; uint8_t buf2[260] = {0}; //switch_stun_packet_header_t *header; printf("buf1 starts at %x\n",buf1); printf("j starts at %x\n",&j); printf("buf2 starts at %x\n",buf2); } ------------------------------