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 
instructions (
 ) 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" <>
> > 
> > Op Thu, 22 Feb 2018 22:51:12 +0100 schreef Mark Kettenis  
> > <>:
> > > 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.
> Cheers,
> Mark

  Brandon Bergren
  Technical Generalist

Reply via email to