Apparently, the control bit only controls whether the cpu will automatically do
fixups for word or smaller single load/store. Targeting an unaligned address
with a *multiple* load/store instruction will still fault. Over in Linux land,
there's this giant grody handler that has emulation for the faultable
) so they can pretend everything is normal and fine...
Somewhat related random blog post:
As per A3.2.1 in the architecture reference manual, the only thing the bit
controls is whether the specific instructions that have hardware fixups (which
isn't even half of the ones that can fault!) will do such fixups in the
background. It's not a "magic bit that makes the cpu act as if it's fine with
unaligned access", it just means you can get away with a slightly less complex
fault handler. And the current fault handler boils down to shooting the
offending process in the head.
Which seems to me like a valid thing to do.
On Fri, Feb 23, 2018, at 6:49 AM, Mark Kettenis wrote:
> > Date: Fri, 23 Feb 2018 12:11:23 +0100
> > From: "Boudewijn Dijkstra" <mailinglists.boudew...@indes.com>
> > Op Thu, 22 Feb 2018 22:51:12 +0100 schreef Mark Kettenis
> > <mark.kette...@xs4all.nl>:
> > > I hate to loose yet another strict-alignment canary, but the reality
> > > is that the rest of the world assumes that armv7 supports unaligned
> > > access which means that compilers generate code that assumes this
> > > works when compiling code for armv7 and later (e.g. NEON code) and
> > > that hand-written assembler code assumes this works as well.
> > Both gcc and clang have -munaligned-access in effect by default on ARMv7.
> That depends on the OS. For OpenBSD -mno-unaligned-access is the
> default, at least for clang. And our base gcc barely supported armv7
> and we configured it for some armv6 variant.
> > So if CPU_CONTROL_AFLT_ENABLE is turned on, then all code should be
> > compiled with -mno-unaligned-access. I cannot find any use of this option
> > in the source tree. Am I missing something?
> See above.
> But even with -mno-unaligned-access clang generates code that doesn't
> work with the SCTLR.A set to 1. The particular case I encountered was
> a floating-point or vector instruction that needs 8-byte alignment
> where the operand was only 4-byte aligned. That's a bug in clang/llvm
> of course, but since both Linux and Darwin set SCTRL.A to 0 such bugs
> are simply not caught.