Date: Fri, 25 Dec 2015 16:56:46 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 205602] arm (rpi2) context: issue identified for Bus Errors from some software (such as ar). . . Message-ID: <bug-205602-7@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205602 Bug ID: 205602 Summary: arm (rpi2) context: issue identified for Bus Errors from some software (such as ar). . . Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net I was getting Bus Errors during attempts to build ports on a rpi2, such as during /usr/local/arm-gnueabi-freebsd/bin/ar activity. That example traced back to _fseeko use and the memset use at line 299 of /usr/src/lib/libc/stdio/fseek.c that was in use via /usr/lib/debug/lib/libc.so.7 : #0 0x2033adcc in _fseeko (fp=0x20651dcc, offset=<value optimized out>, whence=<value optimized out>, ltest=<value optimized out>) at /usr/src/lib/libc/stdio/fseek.c:299 299 memset(&fp->_mbstate, 0, sizeof(mbstate_t)); . . . (gdb) x/24i 0x2033adb0 0x2033adb0 <_fseeko+836>: vmov.i32 q8, #0 ; 0x00000000 0x2033adb4 <_fseeko+840>: movw r1, #65503 ; 0xffdf 0x2033adb8 <_fseeko+844>: stm r4, {r0, r7} 0x2033adbc <_fseeko+848>: ldrh r0, [r4, #12] 0x2033adc0 <_fseeko+852>: and r0, r0, r1 0x2033adc4 <_fseeko+856>: strh r0, [r4, #12] 0x2033adc8 <_fseeko+860>: add r0, r4, #216 ; 0xd8 0x2033adcc <_fseeko+864>: vst1.64 {d16-d17}, [r0] 0x2033add0 <_fseeko+868>: add r0, r4, #200 ; 0xc8 0x2033add4 <_fseeko+872>: vst1.64 {d16-d17}, [r0] 0x2033add8 <_fseeko+876>: add r0, r4, #184 ; 0xb8 0x2033addc <_fseeko+880>: vst1.64 {d16-d17}, [r0] 0x2033ade0 <_fseeko+884>: add r0, r4, #168 ; 0xa8 0x2033ade4 <_fseeko+888>: vst1.64 {d16-d17}, [r0] 0x2033ade8 <_fseeko+892>: add r0, r4, #152 ; 0x98 0x2033adec <_fseeko+896>: vst1.64 {d16-d17}, [r0] 0x2033adf0 <_fseeko+900>: add r0, r4, #136 ; 0x88 0x2033adf4 <_fseeko+904>: vst1.64 {d16-d17}, [r0] 0x2033adf8 <_fseeko+908>: add r0, r4, #120 ; 0x78 0x2033adfc <_fseeko+912>: vst1.64 {d16-d17}, [r0] 0x2033ae00 <_fseeko+916>: add r0, r4, #104 ; 0x68 0x2033ae04 <_fseeko+920>: vst1.64 {d16-d17}, [r0] 0x2033ae08 <_fseeko+924>: b 0x2033b070 <_fseeko+1540> 0x2033ae0c <_fseeko+928>: cmp r5, #0 ; 0x0 (gdb) info all-registers r0 0x20651ea4 543497892 . . . When SCTLR bit[1] == 1 the vst1.64 instructions require 8 byte alignment but the address in r0 is only 4 byte aligned (as was the address of the start of the containing FILE structure). (FILE start address probably from a memory allocator?) I did another build/install world/kernel with "-fmax-type-align=4" added and the same port now builds fine on the rpi2, no tools getting Bus Errors. (make.conf on the rpi2 also causing -fmax-type-align=4 to be used.) So if SCTLR bit[1]==1 is supposed to be true/possible and if various memory allocator alignments are not to be to sufficiently big figures, then it appears that the standard clang 3.7 compile options for armv6/armv7a need to prevent presuming bigger alignment figures than 4 for pointers of unknown origin (or from memory allocators). Note: My experiments were with -march=armv7a explicitly in use, not just -target armv6--freebsd11.0-gnueabi . -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-205602-7>