From owner-freebsd-toolchain@freebsd.org Fri Dec 25 07:06:12 2015 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D5DAA514F5 for ; Fri, 25 Dec 2015 07:06:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D704919C8 for ; Fri, 25 Dec 2015 07:06:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6397 invoked from network); 25 Dec 2015 06:39:36 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Dec 2015 06:39:36 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 25 Dec 2015 01:39:31 -0500 (EST) Received: (qmail 21550 invoked from network); 25 Dec 2015 06:39:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Dec 2015 06:39:31 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3AA1BB1E001; Thu, 24 Dec 2015 22:39:23 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error? Message-Id: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> Date: Thu, 24 Dec 2015 22:39:29 -0800 To: freebsd-arm@freebsd.org, FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2015 07:06:12 -0000 [I do not know if this partial crash analysis related to on-arm = clang-associated activity is good enough and appropriate to submit or = not.] The /usr/local/arm-gnueabi-freebsd/bin/ar on the rpi2b involved below = came from pkg install activity instead of port building. Used as-is. When I just tried my first from-rpi2b builds (ports for a rpi2b), = /usr/local/arm-gnueabi-freebsd/bin/ar crashed. I believe that the = following suggests an alignment error for the type of instructions that = memset for 128 bytes was translated to (sizeof(mbstate_t)) in the code = used by /usr/local/arm-gnueabi-freebsd/bin/ar. (But I do not know how to = check SCTLR bit[1] to be directly sure that alignment was being = enforced.) The crash was a Bus error in /usr/local/arm-gnueabi-freebsd/bin/ar : > libtool: link: /usr/local/arm-gnueabi-freebsd/bin/ar cru = .libs/libgnuintl.a bindtextdom.o dcgettext.o dgettext.o gettext.o = finddomain.o hash-string.o loadmsgcat.o localealias.o textdomain.o = l10nflist.o explodename.o dcigettext.o dcngettext.o dngettext.o = ngettext.o pluralx.o plural-exp.o localcharset.o threadlib.o lock.o = relocatable.o langprefs.o localename.o log.o printf.o setlocale.o = version.o xsize.o osdep.o intl-compat.o > Bus error (core dumped) > *** [libgnuintl.la] Error code 138 It failed in _fseeko doing a memset that turned into uses of "vst1.64 = {d16-d17}, [r0]" instructions, for an address in register r0 that ended = in 0xa4, so was not aligned to 8 byte boundaries. =46rom what I read = such "VSTn (multiple n-element structures)" that have .64 require 8 byte = alignment. The evidence of the code and register value follow. > # gdb /usr/local/arm-gnueabi-freebsd/bin/ar = /usr/obj/portswork/usr/ports/devel/gettext-tools/work/gettext-0.19.6/gette= xt-tools/intl/ar.core > . . . > #0 0x2033adcc in _fseeko (fp=3D0x20651dcc, offset=3D, whence=3D, ltest=3D) 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 > r1 0xffdf 65503 > r2 0x0 0 > r3 0x0 0 > r4 0x20651dcc 543497676 > r5 0x0 0 > r6 0x0 0 > r7 0x0 0 > r8 0x20359df4 540384756 > r9 0x0 0 > r10 0x0 0 > r11 0xbfbfb948 -1077954232 > r12 0x2037b208 540520968 > sp 0xbfbfb898 -1077954408 > lr 0x2035a004 540385284 > pc 0x2033adcc 540257740 > f0 0 (raw 0x000000000000000000000000) > f1 0 (raw 0x000000000000000000000000) > f2 0 (raw 0x000000000000000000000000) > f3 0 (raw 0x000000000000000000000000) > f4 0 (raw 0x000000000000000000000000) > f5 0 (raw 0x000000000000000000000000) > f6 0 (raw 0x000000000000000000000000) > f7 0 (raw 0x000000000000000000000000) > fps 0x0 0 > cpsr 0x60000010 1610612752 The syntax in use for vst1.64 instructions does not explicitly have the = alignment notation. Presuming that the decoding is correct then from = what I read the following applies: > Home > NEON and VFP Programming > NEON load and store element and = structure instructions > Alignment restrictions in load and store, = element and structure instructions >=20 > . . . When the alignment is not specified in the instruction, the = alignment restriction is controlled by the A bit (SCTLR bit[1]): > =E2=80=A2 if the A bit is 0, there are no alignment = restrictions (except for strongly ordered or device memory, where = accesses must be element aligned or the result is unpredictable) > =E2=80=A2 if the A bit is 1, accesses must be element = aligned. > If an address is not correctly aligned, an alignment fault occurs. So if at the time the "A bit" (SCTLR bit[1]) is 1 then the Bus error = would have the context to happen because of the mis-alignment. The following shows the make.conf context that explains how = /usr/local/arm-gnueabi-freebsd/bin/ar came to be invoked: > # more /etc/make.conf=20 > WRKDIRPREFIX=3D/usr/obj/portswork > WITH_DEBUG=3D > WITH_DEBUG_FILES=3D > MALLOC_PRODUCTION=3D > # > TO_TYPE=3Darmv6 > TOOLS_TO_TYPE=3Darm-gnueabi > CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a > CXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a > CPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a > .export CC > .export CXX > .export CPP > AS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as > AR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar > LD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld > NM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm > OBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy > OBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump > RANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib > SIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size > #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings > STRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings > .export AS > .export AR > .export LD > .export NM > .export OBJCOPY > .export OBJDUMP > .export RANLIB > .export SIZE > .export STRINGS > .endif Other context: > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r292413M: Tue Dec 22 = 22:02:21 PST 2015 = root@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = 1100091 1100091 I will note that world and kernel are my own build of -r292413 (earlier = experiment) --a build made from an amd64 host context and put in place = via DESTDIR=3D. My expectation would be that the amd64 context would not = be likely to have similar alignment restrictions involved in its ar = activity (or other activity). That would explain how I got this far = using such a clang 3.7 related toolchain for targeting an rpi2 before = finding such a problem. =3D=3D=3D Mark Millard markmi at dsl-only.net