Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jan 2017 13:27:25 -0700
From:      Sean Bruno <sbruno@freebsd.org>
To:        freebsd-arm@freebsd.org
Subject:   Re: qemu-arm-static appears to have problems with signal delivery during (at least) poudrirer-devel based cross builds of some ports with ALLOW_MAKE_JOBS=yes
Message-ID:  <9d7129d7-da2d-18e9-38ae-06f3483450f7@freebsd.org>
In-Reply-To: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net>
References:  <BF74B3CA-9BD6-4F97-B472-FF918FCE737A@dsl-only.net> <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--iDC9UffDCoeC8bDiDXooSa2RPuNMRcG5f
Content-Type: multipart/mixed; boundary="9jrvaednJqI38xx228eR02VkUCXWhQdOo";
 protected-headers="v1"
From: Sean Bruno <sbruno@freebsd.org>
To: freebsd-arm@freebsd.org
Message-ID: <9d7129d7-da2d-18e9-38ae-06f3483450f7@freebsd.org>
Subject: Re: qemu-arm-static appears to have problems with signal delivery
 during (at least) poudrirer-devel based cross builds of some ports with
 ALLOW_MAKE_JOBS=yes
References: <BF74B3CA-9BD6-4F97-B472-FF918FCE737A@dsl-only.net>
 <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net>
In-Reply-To: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net>

--9jrvaednJqI38xx228eR02VkUCXWhQdOo
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Mark:

There was a recent update this week that was submitted and accepted to
qemu-user-static.

Want to give it a spin again and see if you are able to make progress?

sean "top poster for maximum effect" bruno

On 01/15/17 07:09, Mark Millard wrote:
> On 2017-Jan-14, at 10:53 PM, Mark Millard <markmi at dsl-only.net> wrot=
e:
>=20
>> [Context: head (12) -r312009 and ports head -r431413.]
>>
>> I've been experimenting on amd64 with poudriere-devel with -x
>> for -a arm.armv6 and I ran into:
>>
>>> TCG temporary leak before 00021826
>>> qemu: uncaught target signal 4 (Illegal instruction) - core dumped
>>
>> in 3 of the 31 ports for the build, but 4 skipped so 3 of 27
>> attempted. The 00021826 is the same number in all the examples
>> so far (whatever its base).
>>
>> These seem to be the only TCG messages and each failure starts with
>> one and then reports the qemu message. (Also true for the below.)
>> As far as I can tell the TCG notice is the report of an internal
>> qemu problem that is then translated into an Illegal instruction.
>>
>> This was with ALLOW_MAKE_JOBS=3Dyes but -J 1 for poudriere.
>>
>> For 2 of the problem ports retries worked, still using
>> ALLOW_MAKE_JOBS=3Dyes and -J 1 .
>>
>> But the 3rd port failed each time tried with ALLOW_MAKE_JOBS=3Dyes
>> --but in a different step each time.
>>
>> In all failure cases it was gmake that got the "illegal instruction".
>>
>> But disabling ALLOW_MAKE_JOBS=3Dyes appears (so far) to avoid the
>> issue. For example, that 3rd failing port built fine. (I've
>> been doing more ports since, with ALLOW_MAKE_JOBS=3Dyes repeatedly
>> failing and lack of it working.)
>>
>> My guess is SIGCHLD delivery sometimes touches something (or a timing)=

>> that is not handled well in qemu-arm-static. I've had not problems
>> on an rpi2 or bpim3 in the past.
>>
>> (I have seen some analogous "soemtimes" issues on powerpc under
>> and version of lang that mishandled the stack part of the ABI
>> FreeBSD uses, SIGCHLD sometimes getting on the stack at a bad-time
>> for the messed up code generation, leading to stack corruption. Code
>> not getting signals had no problems.)
>>
>> Note: The amd64 context is FreeBSD under VirtualBox under macOS
>> and it has had no problem for native builds of world, kernel,
>> or ports.
>=20
> Avoiding ALLOW_MAKE_JOBS=3Dyes is not sufficient to guarantee builds
> will work. Here is one that got near the end before failing the
> same way:
>=20
> . . .
> install -m 0644 /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3=
=2E0/gcc/cp/type-utils.h /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/=
stage/usr/local/lib/gcc/arm-none-eabi/6.3.0/plugin/include/cp/type-utils.=
h
> install: DONTSTRIP set - will not strip installed binaries
> TCG temporary leak before 00021826
> qemu: uncaught target signal 4 (Illegal instruction) - core dumped
> gmake[1]: *** [Makefile:4176: install-gcc] Illegal instruction
> gmake[1]: Leaving directory '/wrkdirs/usr/ports/devel/arm-none-eabi-gcc=
/work/.build'
> *** Error code 2
>=20
> Stop.
> make: stopped in /usr/ports/devel/arm-none-eabi-gcc
> =3D=3D=3D=3D>> Cleaning up wrkdir
> =3D=3D=3D>  Cleaning for arm-none-eabi-gcc-6.3.0
> build of devel/arm-none-eabi-gcc ended at Sun Jan 15 00:04:02 PST 2017
> build time: 02:52:28
> !!! build failure encountered !!!
>=20
>=20
> Going back to the earlier initial problem (that I happen to have the
> material for handy): expanding the .tbz of the failed build and finding=

> the core showed:
>=20
> # find . -name "*.core" -exec file {} \;                               =
                                                                         =
                                                                         =
                                           ./work/binutils-2.27/ld/qemu_g=
make.core: ELF 32-bit LSB core file ARM, version 1 (FreeBSD), FreeBSD-sty=
le, from 'ke'
>=20
> [I've not figured out what I can do with that --or how.]
>=20
>=20
> One thing unusual on my part is that I use -mcpu=3Dcortex-a7 . That
> matches how I historically buildworld buildkernel for installation
> on the rpi2 and bpim3. I've never had problems like this with
> builds on the rpi2 or the bpim3 (buildworld, buildkernel, port
> builds). It might be that qemu-arm-static has a problem with
> -mcpu=3Dcortex-a7 code that is generated --but not always.
>=20
> Using the make.conf as an example:
>=20
> # more /usr/local/etc/poudriere.d/head-cortex-a7-make.conf
> WANT_QT_VERBOSE_CONFIGURE=3D1
> #
> DEFAULT_VERSIONS+=3Dperl5=3D5.24
> WITH_DEBUG=3D
> WITH_DEBUG_FILES=3D
> MALLOC_PRODUCTION=3D
> #
> #system clang 3.8+ (gcc6 rejects -march=3Darmv7a):
> #CFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7
> #CXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7
> #CPPFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7
> #
> #lang/gcc6's xgcc stage considers the above conflicting so use just:
> CFLAGS+=3D -mcpu=3Dcortex-a7
> CXXFLAGS+=3D -mcpu=3Dcortex-a7
> CPPFLAGS+=3D -mcpu=3Dcortex-a7
>=20
>=20
> For my context poudriere with -x for -a arm.armv6 and the use of
> qemu-arm-static does not look reliable enough to depend on. It is
> not obvious that the -x use contributes to the problem: it may well
> not.
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
>=20
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
>=20


--9jrvaednJqI38xx228eR02VkUCXWhQdOo--

--iDC9UffDCoeC8bDiDXooSa2RPuNMRcG5f
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEuq1GMucSHejSCZfdEgHvyh5yfmQFAliJCi1fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJB
QUQ0NjMyRTcxMjFERThEMjA5OTdERDEyMDFFRkNBMUU3MjdFNjQACgkQEgHvyh5y
fmSaJQf/f22OiPSKJZz84kuwRC192MdBh96yAS6RKLUvGBFxnpPEY131Jjcl3++q
lakNHiJigrH/2zdDpVaeUtnd4Wui3Zo5c5D5HB8vRgPCo9iXVkACleR202JmpSnV
Wn/mY69zhXsRnJySROzOh1cuFw57ZEzCovNvZXp7I1qVX+wchDhqzgvJUPNobknr
NUEyPaL3x5NY5+oFKjICTL2D4L2jvg3Ovv2h9YqOF2Lfl3O54dtnffQMrvWSXpU2
sjx4yCZxpdEEAkQC9cm5IF7OFzBdvInXiBOxDRR0JstlC8Wqe6eKZeWyePcRcvBs
2ei4jKnbYxEKvZCHuuyUynEvjpwmOw==
=cDyU
-----END PGP SIGNATURE-----

--iDC9UffDCoeC8bDiDXooSa2RPuNMRcG5f--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9d7129d7-da2d-18e9-38ae-06f3483450f7>