From owner-freebsd-arm@freebsd.org Thu Jan 26 13:54:14 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 7AA71CC1922 for ; Thu, 26 Jan 2017 13:54:14 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wj0-x241.google.com (mail-wj0-x241.google.com [IPv6:2a00:1450:400c:c01::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F386A240; Thu, 26 Jan 2017 13:54:13 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wj0-x241.google.com with SMTP id kq3so4678111wjc.3; Thu, 26 Jan 2017 05:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:references:to:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dweYhMuA3kHdqKvGb4697yXZSEiv0Dib73zAQzcvGOw=; b=KmerscTNuFRe/AKHsu8eTPvDqGDhLES9OSqz6rdv5/rzpguqzJun88fxrmAN3Gcfjd dHCIblLb2A4fwgKs/3DURhk/ozx+1+EydksU6cZ9MqEkwoFM5TxCAp9R0RnHvnDibBRQ 3/MRWS6fH4ROeD0/3MNbNainT9D1qbhGXPUqb1V48uK1FrwszwzQ6WtlJbPWBxxzPwGk xPfsewpHJg3aomRAad1SuL0+FUcSmbBtPzTLyivKVHhTeREr8L0Mm1MphmrhvnHia9zB 7v6ifaYeMu0aZflaTs7jdrr4mhF1s/pE67PUA5vwIec9YGXw9aZAbPwZjzfyVAe9LIOc gAvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:references:to:cc :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=dweYhMuA3kHdqKvGb4697yXZSEiv0Dib73zAQzcvGOw=; b=anotj1Sf+gtbwO0IBCDX9eVgCBBm37UAGy2eeEIam6CbmvR/m++juq+tJmNDQ4CxCS UqQkHjKZWFKtEG2Io/6tO5tCRQIxZa/7wrWa2L27X9T1mUUVwbQz9P0ii13QGS4KZUDO cHGzRnkFjKW3Ksm/gaMZ6OgSiXPWkT+oCl3ELVfCxEvNyYrMeqjcBR/TznbNuFA3imcW 9gDHOjT+9uEIhZgaA+XZ11NpMkK/yCEfco7qi0c0zO0Wuj5kg49Mwj4bWccYqWuYBiXV pkJE8lYCgE3BP3J0fIbPPgzeRzqfD/vYAx21k89uDcHQeIgAjj1Evrb0GW/PZUFf5RLC y6VQ== X-Gm-Message-State: AIkVDXIHy0VTTzWKiIKi9bYXAdCJaWuYSH7BgSTzRh/e2KY1WtiEDIdsCLJIbAgZRhm4/A== X-Received: by 10.223.146.39 with SMTP id 36mr2832201wrj.85.1485438850546; Thu, 26 Jan 2017 05:54:10 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id g75sm3829755wme.5.2017.01.26.05.54.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 05:54:10 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: meloun.michal@gmail.com 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> <9d7129d7-da2d-18e9-38ae-06f3483450f7@freebsd.org> <4399212D-B4DD-460F-AD1B-9250FB412B38@dsl-only.net> To: Mark Millard , Sean Bruno Cc: freebsd-arm@freebsd.org Message-ID: <049fd4e6-209b-4385-48ed-f3413ab27e52@gmail.com> Date: Thu, 26 Jan 2017 14:54:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <4399212D-B4DD-460F-AD1B-9250FB412B38@dsl-only.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Thu, 26 Jan 2017 13:54:14 -0000 On 26.01.2017 5:26, Mark Millard wrote: > On 2017-Jan-25, at 12:27 PM, Sean Bruno wrote: > >> 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 > > I updated my /usr/ports to -r432460 (from today) and rebuilt. > I the tried doing some poudriere -x -a arm.armv6 port builds > again, with ALLOW_MAKE_JOBS=yes and -J 1 in use. > > Unfortunately the qemu-user-static update did not fix the > problem I've been seeing. > > An example extracted from a print/texinfo log still shows > "TCG temporary leak before 00021826": I just rebuild print/texinfo without single problem. Well, with slightly different CFLAGS CFLAGS+= -O2 -munaligned-access -mcpu=cortex-a15 -fno-builtin-sin -fno-builtin-cos Michal .... mv warn-on-use.h-t warn-on-use.h /bin/mkdir -p sys rm -f sys/types.h-t sys/types.h && \ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ sed -e 's|@''GUARD_PREFIX''@|GL|g' \ -e 's|@''INCLUDE_NEXT''@|include_next|g' \ -e 's|@''PRAGMA_SYSTEM_HEADER''@|#pragma GCC system_header|g' \ -e 's|@''PRAGMA_COLUMNS''@||g' \ -e 's|@''NEXT_SYS_TYPES_H''@||g' \ -e 's|@''WINDOWS_64_BIT_OFF_T''@|0|g' \ < ./sys_types.in.h; \ } > sys/types.h-t && \ mv sys/types.h-t sys/types.h rm -f unistd.h-t unistd.h && \ .. > > . . . > rm -f sys/types.h-t sys/types.h && \ > { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ > sed -e 's|@''GUARD_PREFIX''@|GL|g' \ > -e 's|@''INCLUDE_NEXT''@|include_next|g' \ > -e 's|@''PRAGMA_SYSTEM_HEADER''@|#pragma GCC system_header|g' \ > -e 's|@''PRAGMA_COLUMNS''@||g' \ > -e 's|@''NEXT_SYS_TYPES_H''@||g' \ > -e 's|@''WINDOWS_64_BIT_OFF_T''@|0|g' \ > < ./sys_types.in.h; \ > } > sys/types.h-t && \ > mv sys/types.h-t sys/types.h > TCG temporary leak before 00021826 > qemu: uncaught target signal 4 (Illegal instruction) - core dumped > Illegal instruction > gmake[2]: *** [Makefile:1174: all-recursive] Error 1 > gmake[2]: Leaving directory '/wrkdirs/usr/ports/print/texinfo/work/texinfo-6.1' > gmake[1]: *** [Makefile:1113: all] Error 2 > gmake[1]: Leaving directory '/wrkdirs/usr/ports/print/texinfo/work/texinfo-6.1' > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** Error code 1 > > Stop. > make: stopped in /usr/ports/print/texinfo > ====>> Cleaning up wrkdir > ===> Cleaning for texinfo-6.1.20160425,1 > build of print/texinfo ended at Wed Jan 25 20:08:32 PST 2017 > build time: 00:06:57 > !!! build failure encountered !!! > > > === > Mark Millard > markmi at dsl-only.net > > On 01/15/17 07:09, Mark Millard wrote: >> On 2017-Jan-14, at 10:53 PM, Mark Millard wrote: >> >>> [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=yes but -J 1 for poudriere. >>> >>> For 2 of the problem ports retries worked, still using >>> ALLOW_MAKE_JOBS=yes and -J 1 . >>> >>> But the 3rd port failed each time tried with ALLOW_MAKE_JOBS=yes >>> --but in a different step each time. >>> >>> In all failure cases it was gmake that got the "illegal instruction". >>> >>> But disabling ALLOW_MAKE_JOBS=yes 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=yes 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. >> >> Avoiding ALLOW_MAKE_JOBS=yes is not sufficient to guarantee builds >> will work. Here is one that got near the end before failing the >> same way: >> >> . . . >> install -m 0644 /wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/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 >> >> Stop. >> make: stopped in /usr/ports/devel/arm-none-eabi-gcc >> ====>> Cleaning up wrkdir >> ===> 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 !!! >> >> >> 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: >> >> # find . -name "*.core" -exec file {} \; ./work/binutils-2.27/ld/qemu_gmake.core: ELF 32-bit LSB core file ARM, version 1 (FreeBSD), FreeBSD-style, from 'ke' >> >> [I've not figured out what I can do with that --or how.] >> >> >> One thing unusual on my part is that I use -mcpu=cortex-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=cortex-a7 code that is generated --but not always. >> >> Using the make.conf as an example: >> >> # more /usr/local/etc/poudriere.d/head-cortex-a7-make.conf >> WANT_QT_VERBOSE_CONFIGURE=1 >> # >> DEFAULT_VERSIONS+=perl5=5.24 >> WITH_DEBUG= >> WITH_DEBUG_FILES= >> MALLOC_PRODUCTION= >> # >> #system clang 3.8+ (gcc6 rejects -march=armv7a): >> #CFLAGS+= -march=armv7-a -mcpu=cortex-a7 >> #CXXFLAGS+= -march=armv7-a -mcpu=cortex-a7 >> #CPPFLAGS+= -march=armv7-a -mcpu=cortex-a7 >> # >> #lang/gcc6's xgcc stage considers the above conflicting so use just: >> CFLAGS+= -mcpu=cortex-a7 >> CXXFLAGS+= -mcpu=cortex-a7 >> CPPFLAGS+= -mcpu=cortex-a7 >> >> >> 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. >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> >> _______________________________________________ >> 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" >> > > > _______________________________________________ > 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" >