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 .
Created attachment 164635 [details] Patch to add -mno-unaligned to world and kernel build I believe the right fix for this may be to add the -mno-unaligned-access option to kernel and world builds, to let the compiler know we have the hardware configured for strict alignment.
Using -fmax-type-align=4 explicit avoids changing the ABI, such as padding properties. "This option does not affect the ABI alignment of types; the layout of structs and unions and the value returned by the alignof operator remain the same." By contrast -mno-unaligned-access is allowed to change the padding instead of accessing in smaller chunks that are put together for the same memory layout. (I've not found a specification of their choices.) I'm not claiming that you are wrong, just that more may change in an incompatible way. Until 11.0 is Release that is probably officially okay. Other notes for -fmax-type-align= quoted from http://clang.llvm.org/docs/UsersManual.html : "Instruct the code generator to not enforce a higher alignment than the given number (of bytes) when accessing memory via an opaque pointer or reference. This cap is ignored when directly accessing a variable or when the pointee type has an explicit “aligned” attribute." "The value should usually be determined by the properties of the system allocator. Some builtin types, especially vector types, have very high natural alignments; when working with values of those types, Clang usually wants to use instructions that take advantage of that alignment. However, many system allocators do not promise to return memory that is more than 8-byte or 16-byte-aligned. Use this option to limit the alignment that the compiler can assume for an arbitrary pointer, which may point onto the heap."
I think this is nothing more than a simple code bug. FILE needs to be int64 aligned because it has the mbstate_t member. findfp.c, however, doesn't know this and just assures ALIGNMENTBYTES alignment, which on arm is 4 not 8. The more proper fix can be found in https://reviews.freebsd.org/D4708 I believe. While there may be other alignment issues, this is just a simple 'oops' in moreglue().
While it has been working for a long time I'll report: As of 11.0 -r301815 building ports shows now such problems in my use. As I understand the patch from Ian Lepore was never used. Also less strict alignment requirements are now in place. But even before that Warner Losh's fix was implemented and it took care of the problem even under the stricter alignment requirements. See comment #3 and its https://reviews.freebsd.org/D4708 reference. (I have no control over Assignee to make the history cleaner since Warner made the actual fix.)