Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Dec 2015 22:39:29 -0800
From:      Mark Millard <markmi@dsl-only.net>
To:        freebsd-arm@freebsd.org, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>
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>

next in thread | raw e-mail | index | archive | help
[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<value optimized =
out>, whence=3D<value optimized out>, ltest=3D<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
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C>