Subject: Re: Enabling alignment faults
To: Steve Woodford <firstname.lastname@example.org>
From: Richard Earnshaw <email@example.com>
Date: 10/24/2003 00:49:23
> 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
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.