1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
<think>
Okay, so I'm trying to figure out why this Docker build is hanging at the `RUN go install -v std` command inside an s390x container on my x86_64 host. Let me start by understanding the setup.
I've got an Ubuntu 18.04 machine with Docker installed, and I'm using QEMU to run s390x containers on this x86_64 host. The Dockerfile provided sets up a Go environment for cross-building s390x binaries. It copies the necessary QEMU static binaries from another stage.
When I run the build command `docker build -t test/crossbuild:latest-s390x -f Dockerfile.s390x .`, it gets stuck at the step where it runs `go install -v std`. This means that Go is trying to recompile its standard library with cgo disabled.
I also tried running this manually inside an s390x container using `docker run -it ...` and encountered the same issue, but with an error message: `Illegal instruction (core dumped)`. That suggests there's a problem with the instructions being executed by the CPU.
Now, considering that I'm on x86_64 and trying to run s390x code, QEMU should be translating those instructions. But if it's failing at this specific Go command, maybe the issue is related to how the Go compiler or runtime interacts with the emulated environment.
The fact that building the same Dockerfile on an actual s390x machine works fine points towards a problem with the emulation setup rather than the Dockerfile itself. So, perhaps there's something missing in the QEMU configuration for the s390x architecture.
Looking deeper into `go install -v std`, it compiles all standard library packages. If cgo is disabled (which it is here), Go should be building static binaries without relying on C libraries. But if during this process, some generated code isn't properly handled by QEMU, it might cause an illegal instruction error.
I wonder if the version of QEMU I'm using has proper support for s390x, especially with cgo disabled. Maybe there's a missing feature or a bug in that specific QEMU build that causes this issue when executing certain Go-compiled code.
Since the problem occurs both during Docker build and manual container execution, it's likely related to how QEMU is handling the guest instructions in user mode. This suggests that the issue is within the user-mode emulation provided by QEMU, rather than system-level components like device drivers or hardware access.
In summary, the bug seems to stem from QEMU's ability to correctly emulate s390x instructions under certain conditions when running Go code with cgo disabled. Since it's about instruction execution and not higher-level system operations, this points towards a user-mode issue.
</think>
user
|