Re: GCC ARM: aligned access
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;
}
func:
0: e590 ldr r0, [r0]
4: e12fff1e bx lr
Regards,
Peng.
Re: GCC ARM: aligned access
On Mon, 1 Sep 2014 09:14:31 +0800 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: 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. Using -munaligned-access (or its inverse) isn't enough to make GCC generate code that can perform arbitrary unaligned accesses, because several instructions (e.g. VFP loads/stores or load/store multiple instructions IIRC) must still act on naturally-aligned data even when the hardware flag to enable unaligned accesses is on, and those instructions will still be generated by GCC when they are considered safe, i.e. when not doing explicitly-unaligned accesses in packed structures or similar. It would be *possible* to add an option to the backend to allow arbitrary alignment for any access, I think, but it's not at all clear that it's a good idea, and would certainly negatively affect performance. (If you need unaligned accesses, you can use e.g. memcpy, and that will probably generate good inline code.) Julian
Re: GCC ARM: aligned access
On 09/02/2014 09:25 PM, Julian Brown wrote: On Mon, 1 Sep 2014 09:14:31 +0800 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: 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. Using -munaligned-access (or its inverse) isn't enough to make GCC generate code that can perform arbitrary unaligned accesses, because several instructions (e.g. VFP loads/stores or load/store multiple instructions IIRC) must still act on naturally-aligned data even when the hardware flag to enable unaligned accesses is on, and those instructions will still be generated by GCC when they are considered safe, i.e. when not doing explicitly-unaligned accesses in packed structures or similar. It would be *possible* to add an option to the backend to allow arbitrary alignment for any access, I think, but it's not at all clear that it's a good idea, and would certainly negatively affect performance. (If you need unaligned accesses, you can use e.g. memcpy, and that will probably generate good inline code.) Thanks for the reply. I've tried memcpy and all is fine. Regards, Peng. Julian
Re: GCC ARM: aligned access
On Mon, Sep 01, 2014 at 09:14:31AM +0800, Peng Fan 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.
int func(u8 *data)
{
return *(unsigned int *)data;
}
I guess -mno-unaligned-access only applies to (potentially) unaligned addresses
that the compiler itself is aware of, like packed struct members.
Otherwise gcc would have to consider *every* memory load/store as
unaligned and break them down into byte loads/stores. In the above case,
you are telling the compiler that you know it is word aligned (by
casting), and the compiler believes you :).
Regards
Senthil
Re: GCC ARM: aligned access
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:
func:
0: e590 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.
Re: GCC ARM: aligned access
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. 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.
Re: GCC ARM: aligned access
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;
}
func:
0: e590 ldr r0, [r0]
4: e12fff1e bx lr
Regards,
Peng.
