On Mon, Sep 1, 2014 at 9:14 AM, Peng Fan <van.free...@gmail.com> wrote: > > > On 09/01/2014 08:09 AM, Matt Thomas wrote: >> >> On Aug 31, 2014, at 11:32 AM, Joel Sherrill <joel.sherr...@oarcorp.com> >> wrote: >> >>>> Hi, >>>> >>>> I am writing some code and found that system crashed. I found it was >>>> unaligned access which causes `data abort` exception. I write a piece >>>> of code and objdump >>>> it. I am not sure this is right or not. >>>> >>>> command: >>>> arm-poky-linux-gnueabi-gcc -marm -mno-thumb-interwork -mabi=aapcs-linux >>>> -mword-relocations -march=armv7-a -mno-unaligned-access >>>> -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float >>>> -pipe -O2 -c 2.c -o 2.o >>>> >>>> arch is armv7-a and used '-mno-unaligned access' >>> >>> I think this is totally expected. You were passed a u8 pointer which is >>> aligned for that type (no restrictions likely). You cast it to a type with >>> stricter alignment requirements. The code is just flawed. Some CPUs handle >>> unaligned accesses but not your ARM. >> > armv7 and armv6 arch except armv6-m support unaligned access. a u8 pointer is > casted to u32 pointer, should gcc take the align problem into consideration > to avoid possible errors? because -mno-unaligned-access. >> While armv7 and armv6 supports unaligned access, that support has to be >> enabled by the underlying O/S. Not knowing the underlying environment, >> I can't say whether that support is enabled. One issue we had in NetBSD >> in moving to gcc4.8 was that the NetBSD/arm kernel didn't enable unaligned >> access for armv[67] CPUs. We quickly changed things so unaligned access >> is supported. > > Yeah. by set a hardware bit in arm coprocessor, unaligned access will not > cause data abort exception. > I just wonder is the following correct? should gcc take the responsibility to > take care possible unaligned pointer `u8 *data`? because > -mno-unaligned-access is passed to gcc. I suppose no. It explicit type conversion, the compiler assumes you take the responsibility I think. Actually you can dump the final rtl using -fdump-rtl-shorten,look at the memory alignment information. In my experiment, it's A32 with -mno-unaligned-access, which means it's 32 bits aligned.
Thanks, bin > > int func(u8 *data) > { > return *(unsigned int *)data; > } > > 00000000 <func>: > 0: e5900000 ldr r0, [r0] > 4: e12fff1e bx lr > > Regards, > Peng. >>