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.
Change-Id: I4d366eb0af1b2936bca369fd28014fb829228ad5
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
