> Date: Tue, 27 Feb 2018 23:09:24 +1100 > From: Jonathan Gray <j...@jsg.id.au> > > On Thu, Feb 22, 2018 at 10:51:12PM +0100, Mark Kettenis wrote: > > 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. I hit > > yet another case of this while playing around with softfp. > > > > The diff below stops the kernel from generating alignment faults as a > > first step. > > > > ok? > > If not doing this is getting in the way of better fp/neon support > I think it is worth doing. ok jsg@
After some further analysis I found out that the code generated by clang is perfectly fine but that our defenition of _ALIGNBYTES in <arm/_types.h> is wrong which results in fts(3) returning a misaligned buffer. There may still be issues with handwritten assembly code but for now I'm going to drop this diff. > > Index: arch/arm/arm/cpufunc.c > > =================================================================== > > RCS file: /cvs/src/sys/arch/arm/arm/cpufunc.c,v > > retrieving revision 1.52 > > diff -u -p -r1.52 cpufunc.c > > --- arch/arm/arm/cpufunc.c 8 Sep 2017 05:36:51 -0000 1.52 > > +++ arch/arm/arm/cpufunc.c 22 Feb 2018 21:42:35 -0000 > > @@ -395,7 +395,6 @@ armv7_setup() > > | CPU_CONTROL_AFE; > > > > cpuctrl = CPU_CONTROL_MMU_ENABLE > > - | CPU_CONTROL_AFLT_ENABLE > > | CPU_CONTROL_DC_ENABLE > > | CPU_CONTROL_BPRD_ENABLE > > | CPU_CONTROL_IC_ENABLE > > >
