From owner-freebsd-arm@freebsd.org Wed Jan 25 20:27:30 2017 Return-Path: Delivered-To: freebsd-arm@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 1B196CC1A22 for ; Wed, 25 Jan 2017 20:27:30 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 EE94B1652 for ; Wed, 25 Jan 2017 20:27:29 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-248-244.albq.qwest.net [67.0.248.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 738C61928BA for ; Wed, 25 Jan 2017 20:27:28 +0000 (UTC) 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 To: freebsd-arm@freebsd.org References: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net> From: Sean Bruno Message-ID: <9d7129d7-da2d-18e9-38ae-06f3483450f7@freebsd.org> Date: Wed, 25 Jan 2017 13:27:25 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7AF92A3C-3563-4B2E-B14A-D6BAF30A16A2@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iDC9UffDCoeC8bDiDXooSa2RPuNMRcG5f" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 20:27:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iDC9UffDCoeC8bDiDXooSa2RPuNMRcG5f Content-Type: multipart/mixed; boundary="9jrvaednJqI38xx228eR02VkUCXWhQdOo"; protected-headers="v1" From: Sean Bruno 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: <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 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--