From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21928 invoked by alias); 3 Feb 2012 09:52:43 -0000 Received: (qmail 21920 invoked by uid 22791); 3 Feb 2012 09:52:42 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_BJ X-Spam-Check-By: sourceware.org Received: from mail-tul01m020-f169.google.com (HELO mail-tul01m020-f169.google.com) (209.85.214.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 03 Feb 2012 09:52:29 +0000 Received: by obbta7 with SMTP id ta7so5109465obb.0 for ; Fri, 03 Feb 2012 01:52:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.76.229 with SMTP id n5mr6014004obw.14.1328262749093; Fri, 03 Feb 2012 01:52:29 -0800 (PST) Received: by 10.60.39.202 with HTTP; Fri, 3 Feb 2012 01:52:29 -0800 (PST) In-Reply-To: References: Date: Fri, 03 Feb 2012 09:52:00 -0000 Message-ID: Subject: Re: Compiler Memory Alignment Issue From: Martin Guy To: Richard Koch Cc: crossgcc@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00032.txt.bz2 On 2 February 2012 19:15, Richard Koch wrote: > know that ptr is declared as a pointer to an integer and interpret "*(ptr= + 1)" > as adding 4 BYTES to ptr. > =A0=A0=A0=A0=A0=A0=A0 unsigned char buffer[8], i; > =A0=A0=A0=A0=A0=A0=A0 int *ptr =3D (int *) buffer; > > =A0=A0=A0=A0=A0=A0=A0 printf("size of int is: %d\n", sizeof(int)); > =A0=A0=A0=A0=A0=A0=A0 memset(buffer, 0xff, sizeof buffer); > > =A0=A0=A0=A0=A0=A0=A0 *(ptr + 1) =3D 0x1234; > > =A0=A0=A0=A0=A0=A0=A0 for (i=3D0; i<(sizeof(buffer) +1); i++) > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 printf("buffer[%d]=3D%x\n",= i, buffer[i]); > } > > > RESULTS WITH crosstool-linux-gnueabi-2005q3-2: > > size of int is: 4 > buffer[0]=3Dff > buffer[1]=3Dff > buffer[2]=3Dff > buffer[3]=3Dff > buffer[4]=3D34 > buffer[5]=3D12 > buffer[6]=3D0 > buffer[7]=3D0 > buffer[8]=3D0 > > RESULTS WITH crosstools-ng: > > size of int is: 4 > buffer[0]=3Dff > buffer[1]=3D34 > buffer[2]=3D12 > buffer[3]=3D0 > buffer[4]=3D0 > buffer[5]=3Dff > buffer[6]=3Dff > buffer[7]=3Dff > buffer[8]=3D8 I can reproduce your first result with gcc.4,4 and your second result with gcc-4.3 (plain native debian compilers), which corresponds to the gcc version you are using in crosstool. The problem is that your char buffer is not word-aligned, so you can't poke ints into it with predictable results. On ARM a nonaligned word access writes into *(int*)(char *)ptr & ~3) and the value it writes is byte-rotated in such a way as to write the least significant byte into *(char *)ptr. It looks like, in your failing case, that the bottom two bits of the address of buffer[0] are 1 and 1. The results also depend on the setting of /pro/cpu/alignment. The default value of 0 gives the above behaviour, echo 4 > /proc/cpu/alignment will cause a fatal signal on misaligned word accesses and echo 2 > /proc/cpu/alignment will trap the misaligned access in the kernel and do what you are expecting (i386- and vax-like behaviour). A more robust solution would be to declare char buffer[8] __attribute__ ((aligned (sizeof(int)))); or int buffer[2]; A further test you can run to verify whether it is the compiler bug you suspect or an alignment issue is to disassemble the object code with arm-linux-gnueabi-objdump -d a.out | less (or whatever your toolchain is called) to check whether it is adding one or four to the pointer. M -- For unsubscribe information see http://sourceware.org/lists.html#faq