> While mucking around with a wi(4) card on an xscale board, and falling 
> foul of kern/23238, it occurred to me that perhaps we should provide a 
> kernel config file option to enable alignment faults.
> 
> To that end, I rattled up "options ARM_ENABLE_ALIGNMENT_FAULTS" together 
> with the necessary glue in fault.c, and cp15 frobbing (for xscale only 
> right now) in cpufuncs.c.
> 
> Running a kernel with this enabled immediately showed up a bug in memcmp 
> (mea culpa ;-) which I have since fixed. Other than that, both kernel 
> and userland are running fine.
> 
> There is an old comment in an earlier version of fault.c which alludes 
> to gcc taking advantage of misaligned accesses when dealing with short 
> ints. I can see how this would be useful on ARM cpus which can't do 
> 16-bit loads/stores, but is it really relevant for more recent cpus? 
> Does gcc still emit such code if the target cpu can do 16-bit ldr/str? 
> If not, then perhaps I should enable it by default and change the 
> option to ARM_DISABLE_ALIGNMENT_FAULTS...
> 

It should be safe to enable alignment faults unless COMPAT_15 is defined.

When we switched to ELF we made the compiler not generate word accesses 
for doing half-word loads, unless the compiler could guarantee that the 
word being loaded was aligned (eg, because it is part of a word-aligned 
structure).

If you want to be really clever, a COMPAT_15 kernel could diddle with the 
alignment configuration whenever an a.out format binary was being run.

It's just possible that some emulations may also require alignment faults 
disabling.  I don't think linux compatibility does; they've been using 
strict alignment for a long time now.

R.