Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
I seem to recall a bug where some CPU models don't properly set registers after a CPUID instruction (e.g., http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/i386/locore.s#rev1.150). Is it possible this CPU is one of those? Maybe Go needs similar workarounds? A way to test that hypothesis would be to add MOVL $0, BX MOVL $0, CX MOVL $0, DX before each of these CPUID instructions: src/cmd/dist/cpuid_386.s:9: CPUID src/runtime/asm_386.s:30: CPUID src/runtime/asm_386.s:47: CPUID On Fri, Aug 7, 2015 at 3:22 PM, Ted Unangst t...@tedunangst.com wrote: Stuart Henderson wrote: I don't think a flavour is warranted, i386 packages are meant to run on all supported CPUs so if the runtime detection is insufficient we should just always set this variable. talk to upstream? this sounds like a bug if the runtime detection is insufficient. unconditionally disabling sse would be a pessimization for most users.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2015/08/07 07:39:36 Modified files: www/firefox-esr: Makefile distinfo www/mozilla-firefox: Makefile distinfo www/firefox-i18n: Makefile.inc distinfo www/firefox-esr-i18n: Makefile.inc distinfo Log message: SECURITY update to firefox 39.0.3 firefox-esr 38.1.1. Fixes MFSA2015-78, see https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/ and https://www.mozilla.org/en-US/security/advisories/mfsa2015-78/ ok naddy@ sthen@
Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
Stuart Henderson wrote: I don't think a flavour is warranted, i386 packages are meant to run on all supported CPUs so if the runtime detection is insufficient we should just always set this variable. talk to upstream? this sounds like a bug if the runtime detection is insufficient. unconditionally disabling sse would be a pessimization for most users.
Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
On Thu, Aug 6, 2015 at 5:54 PM, Stuart Henderson st...@openbsd.org wrote:
I'll see if I can figure something out.
I could get go-1.4.1 and also a backport of -1.4.2 which got just
tagged for OpenBSD 5.8 to work with the patches to Makefile below.
Note that no MAKE_ENV is set. though.
I would expect some, as there's definitely code to do runtime detection.
Indeed, the go binary still includes some SSE instructions that uses
XMM registers, as you indicated probably for detection at run-time.
Today, I want to do more testing using the gopacket library and its
new bsdbpf extension on the PC Engines ALIX, and on APU too.
Regarding the Go port, I am unsure what would be the best way to
proceed, e.g. if a flavor with GO386=387 for i386 without SSE would be
justified for example.
diff for Makefile go-1.4.1 :
@@ -64,7 +67,8 @@
CXX=${CXX} \
GOROOT=${WRKDIST} \
GOBIN=${WRKDIST}/bin \
- GOROOT_FINAL=${GOROOT} ./make.bash --no-banner
+ GOROOT_FINAL=${GOROOT} \
+ GO386=387 ./make.bash --no-banner
do-test:
@cd ${WRKSRC} \
diff for Makefile go-1.4.2 :
@@ -1,6 +1,7 @@
# $OpenBSD: Makefile,v 1.25 2015/05/06 08:28:26 jasper Exp $
-ONLY_FOR_ARCHS = ${GO_ARCHS}
+#ONLY_FOR_ARCHS = ${GO_ARCHS}
+ONLY_FOR_ARCHS =amd64 i386
COMMENT = Go programming language
@@ -64,7 +67,8 @@
CXX=${CXX} \
GOROOT=${WRKDIST} \
GOBIN=${WRKDIST}/bin \
- GOROOT_FINAL=${GOROOT} ./make.bash --no-banner
+ GOROOT_FINAL=${GOROOT} \
+ GO386=387 ./make.bash --no-banner
do-test:
@cd ${WRKSRC} \
Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
On 2015/08/07 08:38, Rolf Sommerhalder wrote: On Thu, Aug 6, 2015 at 5:54 PM, Stuart Henderson st...@openbsd.org wrote: I'll see if I can figure something out. I could get go-1.4.1 and also a backport of -1.4.2 which got just tagged for OpenBSD 5.8 to work with the patches to Makefile below. Note that no MAKE_ENV is set. though. Ah good, that method looks reasonable. I would expect some, as there's definitely code to do runtime detection. Indeed, the go binary still includes some SSE instructions that uses XMM registers, as you indicated probably for detection at run-time. Today, I want to do more testing using the gopacket library and its new bsdbpf extension on the PC Engines ALIX, and on APU too. Regarding the Go port, I am unsure what would be the best way to proceed, e.g. if a flavor with GO386=387 for i386 without SSE would be justified for example. I don't think a flavour is warranted, i386 packages are meant to run on all supported CPUs so if the runtime detection is insufficient we should just always set this variable.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2015/08/07 08:37:27 Modified files: . : INDEX Log message: sync; 9144 for 5.8
