On Fri, Jun 17, 2011 at 11:53:21PM +0100, Paul Brook wrote:
There is still going to be a small cost even in hardware fixup so this is very much worth solving despite it's "becoming invisible" because the chips are hiding / solving it already.
But I believe that h/w feature is turned off in Linux by default. You have to add noalign to the kernel command line to enable.
I think you'll find the hardware fixups are enabled by default on CPUs with that design, quite possibly it can't be turned off.
The situation is much more complicated than that. There are two completely different models for misaligned accesses (v6 and pre-v6). v7 cores are only required to support the former.
However even under the v6 model some instructions will fault on misaligned addresses, and the CPU may be configured to fault many others. The exact behavior depends on the particular instruction chosen by the compiler. I don't know whether Linux currently knows how to enable alignment checking on v6/v7 hardware.
Last time I looked into this, I think the conclusion was that you would have to hack the kernel in order to enable full alignment faulting on v6/v7. The CR.A bit setting may be hardcoded for these arches. (But my knowledge could be out of date...)
However, this slightly misses the point: for linaro, ubuntu and armhf at least, we are interested in fixing apps which incur the cost of alignment faults. Non-faulting misaligned instructions on v6/v7 are therefore much less of a problem, since these are much less expensive.
int main(int argc, char * argv[]) {
char buf[8]; void *v = &buf[1]; unsigned int *p = (unsigned int *)v;This does not (reliably) do what you expect. The compiler need not align buf.
In fact, dereferencing p is unlikely to cause a fault on v6/v7.
Specifically, LDM/STM and LDRD/STRD, plus VFP register loads and stores (but not NEON-specific loads and stores) need to be word aligned and will fault otherwise. These faults are unconditional: the CPU won't do these accesses misaligned natively.
Typically, the compiler emits these instructions when:
a) copying small objects larger than 32 bits (for large objects, memcpy would be used); or
b) accessing fundamental 64-bit types.
Firefox fails under (a); gtk-sharp2 fails under (b). Both cases arise from acting on a misaligned pointer due to an unsafe attempt at optimisation.
Cheers ---Dave