GCC ARM: aligned access

[Joel Sherrill]

On August 31, 2014 8:19:49 AM CDT, Peng Fan <van.freenix@gmail.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'
>
>c code:
>typedef unsigned char u8;                                              
>        
>int func(u8 *data)                                                     
>        
>{                                                                      
>        
>return *(unsigned int *)data;                                          
>
>}
>
>The objdumped asm code is:
>                                                                       
>Disassembly of section .text.func:                                     
>        
>                                                                       
>00000000 <func>:                                                       
>        
>0: e5900000  ldr r0, [r0]                                              
>     
>   4: e12fff1e  bx  lr
>
>from the asm code, we can see that 'ldr r0, [r0]' corresponding to
>'*(unsigned int*)data'. is this correct?
>we can not guarantee that pointer data is 4bytes aligned. If pointer
>data is not 4bytes aligned, and aligned 
>access check is enabled by setting a hardware bit in arm coprocessor,
>then `data abort` may occur.
>
>

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.

If you turn on Wall, do you get a warning? 

>Regards,
>Peng.