[Bug 205602] arm (rpi2) context: issue identified for Bus Errors from some software (such as ar). . .

[bugzilla-noreply at freebsd.org]

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 at FreeBSD.org
          Reporter: markmi at 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.