apps/golang-example doesn't work

[nyh]

This is a sub-issue of issue #522 (which discussed golang support) and a cousin of issue #693 (which discussed the other go compiler, gccgo):

apps/golang-example is a trivial "Hello world" application in go, compiled by the classic golang compiler.

When compiled with "c-shared" build mode (currently the default in apps/golang-example/Makefile), we get the following stack trace when running the result:

#4  0x0000000000388bd5 in invalid_opcode (ef=<optimized out>)
    at arch/x64/exceptions.cc:320
#5  <signal handler called>
#6  runtime.rt_sigaction ()
    at /usr/lib/golang/src/runtime/sys_linux_amd64.s:217
#7  0x0000100000ceda2b in runtime.getsig (i=1, ~r1=3998682)
    at /usr/lib/golang/src/runtime/os1_linux.go:354
#8  0x0000100000cfff39 in runtime.initsig (preinit=true)
    at /usr/lib/golang/src/runtime/signal1_unix.go:69
#9  0x0000100000ced33d in runtime.libpreinit ()
    at /usr/lib/golang/src/runtime/os1_linux.go:199
#10 0x0000100000d1e159 in _rt0_amd64_linux_lib ()
    at /usr/lib/golang/src/runtime/rt0_linux_amd64.s:28
#11 0x000000000033ab59 in elf::object::run_init_funcs (this=<optimized out>)
    at core/elf.cc:944

The line causing the invalid opcode is a syscall instruction (frame 6)... See issue #522 and #590

TEXT runtime·rt_sigaction(SB),NOSPLIT,$0-36
        MOVQ    sig+0(FP), DI
        MOVQ    new+8(FP), SI
        MOVQ    old+16(FP), DX
        MOVQ    size+24(FP), R10
        MOVL    $13, AX                 // syscall entry
        SYSCALL
        MOVL    AX, ret+32(FP)
        RET

When compiled in "pie" mode, we get a different stack trace:

#4  0x0000000000388bd5 in invalid_opcode (ef=<optimized out>)
    at arch/x64/exceptions.cc:320
#5  <signal handler called>
#6  runtime.sigtramp () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:234
#7  0x00002000000ff5f8 in ?? ()

TEXT runtime·sigtramp(SB),NOSPLIT,$24
        MOVQ    DI, 0(SP)   // signum
        MOVQ    SI, 8(SP)   // info
        MOVQ    DX, 16(SP)  // ctx
        MOVQ    $runtime·sigtrampgo(SB), AX
        CALL AX  <------
        RET

I'm not sure what is the problem here - how the "CALL" instruction ca generate an invalid opcode exception.... Maybe there is a much more fundamental problem here, like a screwed up IDT which causes a different exception to end up executing random code and causing an invalid opcode exception (just a guess...).

[nyh]

I'm closing this issue: Our support for Go has progressed since, and we are no longer stuck on these particular problems. Issue #850 is a dup of this issue, but demonstrates the situation today so should replace this issue. The parent issue #522 refers to some of the open bugs in OSv's Go support, and we also have a few uncommitted patches from @benoit-canet which solve some (but not all) of the issues, that need to be cleaned up (see comments on the mailing list) and committed.