Rocko revision does not have the go Quark patches

[floion]

Hi,
any plans to update the golang patches for Rocko? Poky Rocko uses go 1.9 and this layer only supports 1.6 and 1.8

Thanks

[floion]

@jan-kiszka maybe?

[jan-kiszka]

I need to recheck, but I vaguely recall that Go 1.9 does not easily allow our patching anymore. In any case, there are currently no plans to move to Go 1.9.

[floion]

Go 1.9 has split out the go runtime to a different recipe apparently. So it looks like go-runtime needs to be patched instead for 1.9

[floion]

In any case, when using with Poky Rocko, there is no go 1.8 recipe available. Would it be possible for meta-iot2000 to provide it?

[jan-kiszka]

One would have to use a layer in an older revision that used to provide us Go. I think I was once using oe-meta-go.

[floion]

Applying the patches to go-runtime yields the following compile error:

| sync/atomic.LoadUint64: missing section for relocation target runtime.cpuid_edx
| sync/atomic.StoreUint64: missing section for relocation target runtime.cpuid_edx
| runtime/internal/atomic.Load64: missing section for relocation target runtime.cpuid_edx
| runtime/internal/atomic.Store64: missing section for relocation target runtime.cpuid_edx
| sync/atomic.LoadUint64: reloc 26 to non-elf symbol runtime.cpuid_edx (outer=runtime.cpuid_edx) 0
| sync/atomic.StoreUint64: reloc 26 to non-elf symbol runtime.cpuid_edx (outer=runtime.cpuid_edx) 0
| runtime/internal/atomic.Load64: reloc 26 to non-elf symbol runtime.cpuid_edx (outer=runtime.cpuid_edx) 0
| runtime/internal/atomic.Store64: reloc 26 to non-elf symbol runtime.cpuid_edx (outer=runtime.cpuid_edx) 0
| sync/atomic.LoadUint64: undefined: "runtime.cpuid_edx"
| sync/atomic.StoreUint64: undefined: "runtime.cpuid_edx"
| runtime/internal/atomic.Load64: undefined: "runtime.cpuid_edx"
| runtime/internal/atomic.Store64: undefined: "runtime.cpuid_edx"

[jan-kiszka]

Yeah, the code changed, and the result of cpuid(1).edx is no longer saves for later use. Will require more than mechanical adaptations...

[floion]

Yeah, unfortunately going forward, there will be pieces of software that won't compile with older golang versions. Already, our moby based balena container engine requires golang 1.9 or newer to compile.

The quick and dirty solution is to revert golang/go@aeee34c

[jan-kiszka]

If you have a working patch set for some newer Go, mind to send a PR? We can still sort out the patch details later.

[floion]

Will send once I have a free slot. Started something else in the meanwhile for the moment

[floion]

Hi. I'm trying to compile go 1.9 with your 3 patches from here: https://github.com/siemens/meta-iot2000/tree/master/meta-iot2000-bsp/recipes-devtools/go/patches-1.8. In addition to this, one also needs to revert golang/go@aeee34c as stated previously.
Now, with these 4 patches applied, go 1.9 compiles if GO386 is exported as 387. If it is exported as quark however, a compile error is thrown:

| ##### Building packages and commands for host, linux/amd64.
| fatal error: unlock of unlocked lock
| 
| runtime stack:
| runtime.throw(0x6f0acc, 0x17)
|       /usr/lib/go/src/runtime/panic.go:605 +0x95
| runtime.unlock(0x85c090)
|       /usr/lib/go/src/runtime/lock_futex.go:109 +0xc2
| runtime.startm(0xc42002c600, 0x85c800)
|       /usr/lib/go/src/runtime/proc.go:1711 +0x81
| runtime.handoffp(0xc42002c600)
|       /usr/lib/go/src/runtime/proc.go:1785 +0x213
| runtime.stoplockedm()
|       /usr/lib/go/src/runtime/proc.go:1813 +0x101
|       /usr/lib/go/src/runtime/proc.go:2203 +0x2cf
| runtime.park_m(0xc420000180)
|       /usr/lib/go/src/runtime/proc.go:2308 +0xb6
| runtime.mcall(0x7ffdf9933010)
|       /usr/lib/go/src/runtime/asm_amd64.s:289 +0x5b
| 
| goroutine 1 [chan receive, locked to thread]:
| text/template/parse.(*lexer).nextItem(...)
|       /usr/lib/go/src/text/template/parse/lex.go:196
| text/template/parse.(*Tree).next(...)
|       /usr/lib/go/src/text/template/parse/parse.go:64
| text/template/parse.(*Tree).nextNonSpace(0xc42011e000, 0x10, 0x37f, 0x6ff60d, 0x1, 0x2d)
|       /usr/lib/go/src/text/template/parse/parse.go:102 +0x1d1
| text/template/parse.(*Tree).pipeline(0xc42011e000, 0x6ea8ff, 0x7, 0x6ff600)
|       /usr/lib/go/src/text/template/parse/parse.go:419 +0x58a
| text/template/parse.(*Tree).action(0xc42011e000, 0x9, 0x370)
|       /usr/lib/go/src/text/template/parse/parse.go:380 +0x195
| text/template/parse.(*Tree).textOrAction(0xc42011e000, 0x7, 0x372)
|       /usr/lib/go/src/text/template/parse/parse.go:348 +0x22c
| text/template/parse.(*Tree).parse(0xc42011e000)
|       /usr/lib/go/src/text/template/parse/parse.go:294 +0x445
| text/template/parse.(*Tree).Parse(0xc42011e000, 0x6ff28e, 0x91d, 0x0, 0x0, 0x0, 0x0, 0xc4200895c0, 0xc42005e8d0, 0x2, ...)
|       /usr/lib/go/src/text/template/parse/parse.go:233 +0x244
| text/template/parse.Parse(0x6e9941, 0x4, 0x6ff28e, 0x91d, 0x0, 0x0, 0x0, 0x0, 0xc42005e8d0, 0x2, ...)
|       /usr/lib/go/src/text/template/parse/parse.go:55 +0x144
| text/template.(*Template).Parse(0xc4200fad80, 0x6ff28e, 0x91d, 0x2, 0xc4200b9caa, 0x6e90c0)
|       /usr/lib/go/src/text/template/template.go:198 +0x125
| cmd/go/internal/test.init()
|       /usr/lib/go/src/cmd/go/internal/test/test.go:1510 +0x320
| main.init()
|       <autogenerated>:1 +0xac
| 
| goroutine 5 [syscall]:
| os/signal.signal_recv(0x0)
|       /usr/lib/go/src/runtime/sigqueue.go:131 +0xa5
| os/signal.loop()
|       /usr/lib/go/src/os/signal/signal_unix.go:22 +0x22
| created by os/signal.init.0
|       /usr/lib/go/src/os/signal/signal_unix.go:28 +0x41
| 
| goroutine 6 [runnable]:
| text/template/parse.(*lexer).emit(0xc4200a6400, 0x10)
|       /usr/lib/go/src/text/template/parse/lex.go:156 +0xc5
| text/template/parse.lexSpace(0xc4200a6400, 0x70a280)
|       /usr/lib/go/src/text/template/parse/lex.go:427 +0x64
| text/template/parse.(*lexer).run(0xc4200a6400)
|       /usr/lib/go/src/text/template/parse/lex.go:231 +0x5f
| created by text/template/parse.lex
|       /usr/lib/go/src/text/template/parse/lex.go:224 +0x15f

Does that ring any bell @jan-kiszka ?

[jan-kiszka]

Hmm... The message sounds like an internal memory corruption of the compiler, maybe an unlock of an invalid lock variable. That would make sense if it ran its own code with Quark tunings (ie. without lock prefixes) on multiple cores. But I don't think it does that.

You could try to nail down the crash by reverting your changes stepwise until it builds again.

[floion]

The compile crash takes place only when changing GO386 to quark from 387. And this is only impacted by https://github.com/siemens/meta-iot2000/blob/master/meta-iot2000-bsp/recipes-devtools/go/patches-1.8/0003-cmd-internal-obj-x86-cmd-compile-internal-x86-Add-In.patch
So this https://github.com/siemens/meta-iot2000/blob/master/meta-iot2000-bsp/recipes-devtools/go/patches-1.8/0003-cmd-internal-obj-x86-cmd-compile-internal-x86-Add-In.patch#L45-L47 seems to be the culprit

[jan-kiszka]

Forward-porting 101: If something subtly breaks around some hunk, check the history of its context: you need to account for golang/go@5437cde#diff-d8fa74b92bd74f06a5fc36f00e5273e0. Maybe that will fix the issue already.

Looking forward to a PR if the patches work!

[mirzak]

Curious if there has been any progress on this that has not been reported back?

I recently hit the same problem, as I wanted to run go 1.9 on IOT2000 board.

[jan-kiszka]

I didn't receive any update from @floion so far. As we are currently updating the rest of the layer, it would be a good time.

[floion]

We updated on our layers like so: balena-os/balena-iot2000@4c3ed2c

However, on our usecase we are currently running into some issues with our implementation of the docker container engine and not entirely sure if it's because of these backports.

I will be getting back to this issue in the near future but until then, @jan-kiszka feel free to use anything from there, give it a test and merge it here if you think it's appropriate.

[rufnut]

Curious if there has been any progress on this that has not been reported back?

I recently hit the same problem, as I wanted to run go 1.9 on IOT2000 board.

This should work with later versions:
https://github.com/rufnut/golang-go_no-mmx

@jan-kiszka thank you for the patches.

I notice later versions of Go seem to optimize closer to 386 code as the switch says.
Earlier versions still had a lot of 686 code in the made binaries with the GOARCH="386" activated.

[mkozjak]

Is this issue also present for IOT2050?

[jan-kiszka]

Nope, see https://support.industry.siemens.com/tf/ww/en/posts/docker-on-iot2050/237321/?page=0&pageSize=10 for more.

[jan-kiszka]

Unless someone contributes a port, Go won't be updated for the Quark anymore.