Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: 386 build with GO386=387 no longer runs on older CPUs #8152

Closed
calmh opened this issue Jun 4, 2014 · 15 comments
Closed

build: 386 build with GO386=387 no longer runs on older CPUs #8152

calmh opened this issue Jun 4, 2014 · 15 comments
Milestone

Comments

@calmh
Copy link
Contributor

calmh commented Jun 4, 2014

Compiling with go1.3rc1, GOARCH=386, GO386=387 creates binaries that cannot run on for
example "AMD Athlon(tm) XP 2400+ by AuthenticAMD". At startup, crashes as
below. Binary compiled with go1.2.2 works.

SIGILL: illegal instruction
PC=0x820638f

goroutine 16 [running]:
math.init·1()
/usr/local/go/src/pkg/math/pow10.go:34 +0x1f fp=0xb7692ef4 sp=0xb7692edc
math.init()
/usr/local/go/src/pkg/math/unsafe.go:21 +0x42 fp=0xb7692ef8 sp=0xb7692ef4
reflect.init()
/usr/local/go/src/pkg/reflect/value.go:2684 +0x48 fp=0xb7692f1c sp=0xb7692ef8
fmt.init()
/usr/local/go/src/pkg/fmt/scan.go:1168 +0x4d fp=0xb7692f58 sp=0xb7692f1c
compress/gzip.init()
/usr/local/go/src/pkg/compress/gzip/gzip.go:271 +0x48 fp=0xb7692f6c sp=0xb7692f58
main.init()
/Users/jb/src/github.com/calmh/syncthing/cmd/syncthing/usage.go:56 +0x57 fp=0xb7692f9c
sp=0xb7692f6c
runtime.main()
/usr/local/go/src/pkg/runtime/proc.c:240 +0xdd fp=0xb7692fd0 sp=0xb7692f9c
runtime.goexit()
/usr/local/go/src/pkg/runtime/proc.c:1445 fp=0xb7692fd4 sp=0xb7692fd0
created by _rt0_go
/usr/local/go/src/pkg/runtime/asm_386.s:101 +0x102

goroutine 17 [runnable]:
runtime.MHeap_Scavenger()
/usr/local/go/src/pkg/runtime/mheap.c:507
runtime.goexit()
/usr/local/go/src/pkg/runtime/proc.c:1445

goroutine 18 [runnable]:
bgsweep()
/usr/local/go/src/pkg/runtime/mgc0.c:1976
runtime.goexit()
/usr/local/go/src/pkg/runtime/proc.c:1445

goroutine 19 [runnable]:
runfinq()
/usr/local/go/src/pkg/runtime/mgc0.c:2606
runtime.goexit()
/usr/local/go/src/pkg/runtime/proc.c:1445

eax 0x1880e0b8
ebx 0x1880e0b8
ecx 0x188020a0
edx 0x0
edi 0xb7771000
esi 0x1880e0b8
ebp 0x17
esp 0xb7692edc
eip 0x820638f
eflags 0x10292
cs 0x73
fs 0x0
gs 0x3f
@minux
Copy link
Member

minux commented Jun 4, 2014

Comment 1:

for GO386=387 builds, you will have to rebuild Go by yourself, otherwise
it won't be effective for standard packages.
please refer to http://golang.org/doc/install/source for details, be sure to
export GO386=387 before running all.bash or make.bash.

Status changed to WaitingForReply.

@ianlancetaylor
Copy link
Member

Comment 2:

Is there a documentation issue here?

Labels changed: added repo-main, release-go1.3maybe.

@calmh
Copy link
Contributor Author

calmh commented Jun 4, 2014

Comment 3:

Hmm. That sounds like it could be the cause. But I also read that GO386=387 is the
default when cross compiling, i.e. this should already have been the case when I built
Go for crosscompilation on darwin/amd64? I admin that "I read" is from some maybe not
authoritative go-nuts post so it may be a misunderstanding...

@calmh
Copy link
Contributor Author

calmh commented Jun 4, 2014

Comment 4:

Edit: the doc/install/source doc also notes that "$GO386 (for 386 only, default is
auto-detected if built natively, 387 if not)".

@minux
Copy link
Member

minux commented Jun 4, 2014

Comment 5:

yeah, there is a problem.
if cross compiling on PC, cmd/dist will detect the host cpu's sse2 capability and
set GO386 based on that.
But, there is another problem if we change this behavior:
if an amd64 user compiles Go for GOARCH=386 without setting GO386 and GOHOSTARCH,
then the new toolchain will only use 387 FP instructions, not sse2 as it is
probably expected by the user.
The other option is to modify the doc/install-source.html to say this:
$GO386 (for 386 only, default is auto-detected if build on 386 or amd64, 387 if not).
Which one do yo prefer?

Owner changed to @minux.

Status changed to Accepted.

@calmh
Copy link
Contributor Author

calmh commented Jun 4, 2014

Comment 6:

I have no problem with the default being to use SSE2 if that is better for most people,
as long as I can recompile it. If I understand you correctly, the situation at the
moment is that as long as I'm compiling go on any kind of x86 CPU, I'm "native" and it
will be autodetected to whatever my CPU can handle? Whereas I assumed "native" meant I
was actually on a 32 bit CPU.
That said, do people really expect those instructions in 32 bit builds? I'm publishing
binary builds for a project of mine, it apparently breaks with SIGILL on a bunch of old
or small (i.e. NAS) hardware out there. Most/all other binaries compiled for 32 bit x86
seem to work fine, i.e. a regular Ubuntu and so on?
I'll recompile everything with GO387=386 and see what happens.

@calmh
Copy link
Contributor Author

calmh commented Jun 4, 2014

Comment 7:

Eh. GO386=387.

@calmh
Copy link
Contributor Author

calmh commented Jun 4, 2014

Comment 8:

Personally, when I'm building for 32 bit I'm not exactly targeting the high performance
systems out there and performance isn't the main driver - compatibility is. So the
capabilities detected on my (quite modern) build box is a poor indicator of the
capabilities of the systems the 32 bit binaries will actually run on.

@minux
Copy link
Member

minux commented Jun 4, 2014

Comment 9:

Re #6, yes, your understanding is right.
I believe we should do something for this issue: either modify
the cmd/dist behavior to match the docs if we interpret "building
natively" as building with GOARCH==GOHOSTARCH, or change the docs
to say GO386 will be auto-detected if building on x86 (both 386
and amd64).
Now I'm leaning towards the docs change for 1.3.
Ian, what's your opinion? It's a small change either way.

@calmh
Copy link
Contributor Author

calmh commented Jun 4, 2014

Comment 10:

Everything works perfectly after recompiling, so there is at least no technical issue
here. Thanks for the support and either of the above tweaks sound fine to me.

@ianlancetaylor
Copy link
Member

Comment 11:

I think we should document that GO386 will be auto-detected.
People can prefer to build 32-bit binaries on their current system just as they can
prefer to build 32-bit binaries for old systems.  I don't think there is a clearly
correct default.  So let's keep the default we have.

@gopherbot
Copy link
Contributor

Comment 12:

CL https://golang.org/cl/102150046 mentions this issue.

@minux
Copy link
Member

minux commented Jun 4, 2014

Comment 13:

This issue was closed by revision ae1b5c7.

Status changed to Fixed.

@gopherbot
Copy link
Contributor

Comment 14:

CL https://golang.org/cl/105830044 mentions this issue.

@minux
Copy link
Member

minux commented Jun 5, 2014

Comment 15:

This issue was closed by revision 055bfb8a7a57.

@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
minux added a commit that referenced this issue May 11, 2015
…ill be auto-detected when building on both 386 and amd64.

««« CL 102150046 / ccf7893cc2f0
doc/install-source.html: document that GO386 will be auto-detected when building on both 386 and amd64.
Fixes #8152.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/102150046
»»»

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/105830044
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants