On August 31, 2014 8:19:49 AM CDT, Peng Fan <van.free...@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.
