summaryrefslogtreecommitdiff
path: root/?id=5e9e5b98f6f1bc482c78412565788f0e34ae42b6
diff options
context:
space:
mode:
authorArne Welzel <arne.welzel@gmail.com>2018-03-21 20:29:58 +0100
committerLionel Sambuc <lionel.sambuc@gmail.com>2018-03-25 11:23:21 +0200
commit5e9e5b98f6f1bc482c78412565788f0e34ae42b6 (patch)
tree3d85fffe2c19603545a3a8c40b98f2f5a3fb1852 /?id=5e9e5b98f6f1bc482c78412565788f0e34ae42b6
parent7c3424c244a54c191c45d2fcfe666588cbf6d11a (diff)
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. Change-Id: I4d366eb0af1b2936bca369fd28014fb829228ad5
Diffstat (limited to '?id=5e9e5b98f6f1bc482c78412565788f0e34ae42b6')
0 files changed, 0 insertions, 0 deletions