This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC ARM: aligned access
- From: "Bin.Cheng" <amker dot cheng at gmail dot com>
- To: Peng Fan <van dot freenix at gmail dot com>
- Cc: Matt Thomas <matt at 3am-software dot com>, Joel Sherrill <joel dot sherrill at oarcorp dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 3 Sep 2014 15:47:17 +0800
- Subject: Re: GCC ARM: aligned access
- Authentication-results: sourceware.org; auth=none
- References: <540320F5 dot 9030501 at gmail dot com> <1cf062bd-289a-4375-ab2b-e34419d22bd3 at email dot android dot com> <7567D3C5-285C-480B-B547-84387E2C4994 at 3am-software dot com> <5403C877 dot 1070807 at gmail dot com>
On Mon, Sep 1, 2014 at 9:14 AM, Peng Fan <van.freenix@gmail.com> wrote:
>
>
> On 09/01/2014 08:09 AM, Matt Thomas wrote:
>>
>> On Aug 31, 2014, at 11:32 AM, Joel Sherrill <joel.sherrill@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.
>>