blob: a10c9843e77b0db961806dd7a713c0a71407cd4b (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
semantic: 0.656
other: 0.631
instruction: 0.607
graphic: 0.565
mistranslation: 0.475
device: 0.311
vnc: 0.261
network: 0.235
boot: 0.229
socket: 0.197
assembly: 0.183
KVM: 0.136
Go binaries panic with "mmap errno 9" on qemu-user
Go binaries panic with "mmap errno 9" on qemu-user.
root@nofan:/# cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
root@nofan:/# gccgo-7 hello.go -o hello
root@nofan:/# ./hello
mmap errno 9
fatal error: mmap
runtime stack:
mmap errno 9
fatal error: mmap
panic during panic
runtime stack:
mmap errno 9
fatal error: mmap
stack trace unavailable
root@nofan:/#
Tested with qemu from git master with Debian unstable for armel.
Same binaries work fine on real hardware.
With current QEMU (and in particular with 4.1.0 rc3 or later with commit 5bfce0b74fbd5d5308 that fixes sigaltstack) go binaries work OK. I think we must have fixed this mmap issue at some point between when this bug was reported and now (or possibly the go runtime was made a bit more forgiving of QEMU's eccentricities).
Oh, that's interesting. I will verify this and if it indeed works, I will enable Go binaries for sh4 in Debian.
Thanks a lot for the update!
I haven't tested sh4 specifically, but arm (subject of this bug report) definitely works, as does arm64.
I can confirm that the issue has been resolved on arm. Unfortunately, on sh4, the Go binaries are still crashing, albeit differently now. I verified that they work fine on real sh4 hardware.
Could you file a separate bug for the sh4 case, then, please (with repro instructions)?
I'm marking this bug as "fix released" now since the Arm problem has been fixed. If there is something else to do for sh4, please open a new bug as suggested by Peter.
|