bsd.own.mk: use -mno-unaligned-access on ARM

Without this option, gcc may emit code accessing unaligned memory. This,
and the fact that SCTRL.A (System Control Register - Alignment Check) is
set to 1 in Minix causes data aborts when such code is encountered.

This was the cause of #104. The `minix-service' executable caused
unaligned memory accesses calling into getpwnam(). These then trigger
data abort exceptions. On ARM, these were previously forwarded to `vm'
as pagefaults. However, `vm' did not properly handle them, but instead
allocated one page for the faulting address (over and over again) and
then resumed the process at the faulting instruction (over and over
again). This behavior masked the whole story as an OOM.

Below the assembly version getpwent.c in which unaligned memory
accesses are even highlighted...

 ...
 341         ldr     lr, [sp, #48]
 342         cmp     lr, #0
 343         bne     .L46
 344         ldr     r0, [r4]        @ unaligned
 345         add     r1, r7, #5
 346         str     r0, [sp, #4]    @ unaligned
 347         ldr     r4, [sp, #4]
 348         mov     r5, r4, asr #31
 349         strd    r4, [r8, #40]
 ...

This should fix #104. It was tested on an actual Beaglebone Black.

An alternative fix would be to disable alignment checking by setting
SCTRL.A to 0 and allowing unaligned memory accesses.

share/mk/bsd.own.mk

@@ -82,6 +82,11 @@ SMP_FLAGS += -DCONFIG_MAX_CPUS=${CONFIG_MAX_CPUS}
 
 CPPFLAGS+= ${SMP_FLAGS}
 
+# Disabled unaligned accesses on ARM
+.if !empty(MACHINE_ARCH:Mearm*)
+CFLAGS+= -mno-unaligned-access
+.endif
+
 __uname_s!= uname -s
 .if ${__uname_s:Uunknown} == "Minix" 
 USETOOLS?=	never