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

runtime/race: cannot run under qemu-user-ppc64le due to execve /proc/self/exe #42080

Open
tie opened this issue Oct 20, 2020 · 3 comments
Open

runtime/race: cannot run under qemu-user-ppc64le due to execve /proc/self/exe #42080

tie opened this issue Oct 20, 2020 · 3 comments

Comments

@tie
Copy link
Contributor

@tie tie commented Oct 20, 2020

What version of Go are you using (go version)?

$ go version
go version go1.15.2 linux/amd64

Does this issue reproduce with the latest release?

Yes, starting with go1.15rc2 up to the latest go1.15.3 release (that is, after e49b230).

What did you do?

  • Set up qemu-user on linux/amd64 host.
  • Run GOARCH=ppc64le go test.

What did you expect to see?

Tests running under QEMU user mode emulation.

What did you see instead?

qemu: unknown option 'test.timeout=10m0s'

The issue is caused by race detector runtime calling execve("/proc/self/exe", …). With user mode emulation this executes QEMU itself instead of the emulated process.

@tie tie changed the title runtime/race: regression under qemu-user-ppc64le due to execve /proc/self/exe runtime/race: cannot run under qemu-user-ppc64le due to execve /proc/self/exe Oct 20, 2020
@bcmills
Copy link
Member

@bcmills bcmills commented Oct 20, 2020

We currently lack a QEMU builder (#1508), and per http://golang.org/wiki/PortingPolicy, supported platforms require builders. Therefore, the QEMU platform is not supported.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 20, 2020

Also, this is an issue with the race detector support libraries which are part of the LLVM project. There is nothing that the Go project can do to fix this problem.

CC @dvyukov

@tie
Copy link
Contributor Author

@tie tie commented Oct 20, 2020

Indeed, that’s mostly an issue with sanitizer and not Go. Both are somewhat tightly coupled though. Concerning the fix, I think we can pass env var to indicate that the executable is run directly from go test (without intermediate “xprog”) and in that case use argv[0] instead of procfs path in LLVM’s ReExec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants