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
runtime: fail nicely on start-up on softfloat mips systems if binary built with GOMIPS=hardfloat (the default) #23614
Comments
Looks like you're missing GOMIPS=softfloat. (Default is hardfloat.) |
This is documented at https://tip.golang.org/doc/go1.10#ports and https://tip.golang.org/cmd/go/#hdr-Environment_variables but I don't see it documented at https://tip.golang.org/doc/install/source It should be documented there if GOARM and GO386 are. (I see it's also at https://tip.golang.org/doc/asm#mips but that's only relevant to a small audience) |
Change https://golang.org/cl/90815 mentions this issue: |
It would also be nice if the binary startup detected the problem and reported a nicer error message than "segmentation fault". |
I'm a little surprised that it is segmentation fault instead of illegal instruction. Either way, I agree that it would be nice to print a nicer error message. On ARM, we do this by querying the HWCAP bits at startup, and see if the GOARM value is compatible with HWCAP. On MIPS, it seems no HWCAP bit for whether it has FPU. Is there something we can query without trapping? |
I'm pretty sure we tested the GOMIPS=softfloat with the go1.10RC1 compiler without much success. We found the relevant information about the soft-float support on MIPS in this issue: #18162. |
I think it's hard to detect fpu presence on mips without triggering SIGILL
though. What I suggest is that for hard float programs, we trigger SIGILL
very early on during startup. Because people seeing SIGILL will most likely
to understand it's a hardware problem than seeing SIGSEGV.
|
I can't reproduce this issue.
|
OK, I can verify that
The result of executing the binary is again a segmentation fault. Our partners have built a kernel with |
A follow-up: we have compiled the sample project with a custom build of GCCGO. The binary still uses hard-float, but now we get the "correct" error message: |
I also cannot reproduce this - GOMIPS=softfloat is working, GOMIPS=hardfloat brings illegal instruction. |
We've attached a gdb to the target and run the program. Unfortunately, the debugger outputs: This probably means that the Go compiler cannot produce a valid executable for the target. This would explain the Unfortunately we have to flash the new firmware onto the device and thus cannot do any further testing of this issue. |
As far as I can tell, only @dtodor was able to recreate the problem, and that is no longer possible. So, closing. Please comment if you disagree. |
We have a problem running a simple Go program on a MIPS target with the following FPU configuration:
On the same target with the CONFIG_MIPS_FPU_EMULATOR enabled, the program runs as expected. My understanding is that the latest release Go compiler only supports hard-float on MIPS, with soft-float implemented in go1.10RC1. Is this correct?
What version of Go are you using (
go version
)?The following Go versions have been tested:
go1.8.3
go1.9.3
go1.10RC1
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?The program is built on OS X:
The target is MIPS32 big endian (GRX550).
What did you do?
Build and run the following sample program: https://play.golang.org/p/XHRe6Hv6Jeb
Build instructions:
What did you expect to see?
The output of the program, e.g.:
What did you see instead?
The program immediately terminates:
The text was updated successfully, but these errors were encountered: