On 05/30/2013 07:42 PM, Mans Rullgard wrote:
On 31 May 2013 00:34, William Millswmills@ti.com wrote:
We are using the Linaro prebuilt binary 2013.03 toolchain. We have a program that does a memcpy of 6 bytes and the source and destination pointers are both 6 byte arrays (through multiple levels of struct& union etc). At -O2 we get the memcpy inlined. The code area in question is: 22840: f8b7 2054 ldrh.w r2, [r7, #84] ; 0x54 22844: f853 1d12 ldr.w r1, [r3, #-18]! 22848: f042 0202 orr.w r2, r2, #2 2284c: 889b ldrh r3, [r3, #4] 2284e: b292 uxth r2, r2 ->22850: f8c7 101a str.w r1, [r7, #26] 22854: f8a7 2054 strh.w r2, [r7, #84] ; 0x54 22858: 83fb strh r3, [r7, #30] 2285a: f8da 3000 ldr.w r3, [sl]
And we get an alignment fault at the str.w marked above. Looking at the types involved and their location in the containing structures I don't see how the compiler could think that the destination was word aligned (I believe it is guaranteed that dest % 8 == 6)
There are no -march -mcpu or -mtune params passed to the compiler. The code is running in user space on a A15.
So what is the default target for the compiler? gcc -v should say how it was configured.
It is the Linaro pre-built toolchain so it is targeting armv7a hardfloat with tune set to cortex-A9.
Basic question before we look further: Is the compiler assuming that cp15 SCTLR.A is 0 so that it is free to generate unaligned loads and stores?
If targeting ARMv6 or later, yes. This is the reset default and the recommended setting.
Thanks Mans. This is exactly the answer I was looking for. I guess we messed up in the kernel init somewhere and turned strict checking on somewhere.
I'm just surprised it has not hit us before. !??!
If the answer to the above is "no" we can isolate the code more and bring it back to the list.
If you, ill-advisedly, enable strict alignment checking, you must compile with -mno-unaligned-access.