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.
int func(u8 *data)
{
return *(unsigned int *)data;
}
00000000 <func>:
0: e5900000 ldr r0, [r0]
4: e12fff1e bx lr
Regards,
Peng.
>
