gccgo: doesn't work on powerpc64 with kernel ucontext functions

[awilfox]

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

$ go version
Aborted

goroutine 16 [running]:
panic during panic

goroutine 16 [running]

goroutine 17 [runnable]:
stack trace unavailable

(GCC 6.4.0 and 7.3.0 were attempted.)

Does this issue reproduce with the latest release?

Untestable as GCC 8 has code generation issues (that are being fixed right now). It's extremely likely that this issue still affects GCC 8 as I am unaware of any attempts to fix this bug, and unable to find any commits that would lead me to believe it is fixed.

What operating system and processor architecture are you using (go env)?

Adélie Linux on ppc64 (big endian) using musl (ELFv2 ABI)

What did you do?

$ go version
$ go help

etc.

What did you expect to see?

Actual output from Go.

What did you see instead?

An Abort trap and a panic during panic.

This is because GCC Go is hard-coded to generate ELFv1 ABI code on big-endian PPC64. This is inaccurate. musl libc uses ELFv2 ABI code on big-endian PPC64. GCC Go should probably use the option from ./configure, --with-abi, to determine which ABI to use on PPC64.

Golang Go isn't usable due to #19074, so our only hope is really GCC Go. I've been trying to figure out where, exactly, gccgo emits its code so that I could fix this issue myself. However, I have been unsuccessful. I've already ported many other large software projects to ELFv2, so a pointer to where the code is that needs to be fixed would, more than likely, allow me to complete this port myself. If upstream GCC Go isn't interested in taking this upstream, I would be willing to distribute it to the community myself for those of us who need this support.

[bdragon28]

FreeBSD powerpc64 (which is BE only) is also moving towards ELFv2 and will likely be affected by the same issue.

[ianlancetaylor]

The gccgo frontend doesn't care at all about ABIs. It is most likely that this is a problem with the GCC backend. If so, it presumably also happens with C code. I recommend that you try a C program. If that fails, then open a bug report on the GCC bug tracker at https://gcc.gnu.org/bugzilla and close this one. If it really is gccgo-specific, add a comment here. Thanks.

[awilfox]

gcc works fine and emits ELFv2 code. go crashes and segfaults. It works correctly on every other musl platform, except PPC64. When I investigated it, I noticed it was jumping to what looked like an ELFv1 function descriptor. Whether this was generated dynamically by the Go runtime, or there is some issue with assembly/linking during build, I cannot fully determine.

[ianlancetaylor]

How exactly did you run the GCC configure script?

What happens if you run gccgo -o hello hello.go for a simple hello.go program? Does the resulting program run?

[awilfox]

No.

awilcox on gwyn [pts/10 Tue 12 7:30] ~: cat -> hello.go
package main

import "fmt"

func main() {
  fmt.Printf("Hello, world, from ppc64\n")
}
awilcox on gwyn [pts/10 Tue 12 7:30] ~: gccgo -o hello hello.go
awilcox on gwyn [pts/10 Tue 12 7:30] ~: ./hello
Aborted


        :0

        :0

        :0

        :0

goroutine 16 [garbage collection]:
panic during panic

goroutine 16 [garbage collection]:

        :0

        :0

        :0

        :0

        :0

        :0

        :0

        :0

        :0

        :0

        :0

        :0

        :0
main.main
        /home/awilcox/hello.go:6

        :0

        :0

        :0
created by main
        /usr/src/packages/system/gcc/src/gcc-6.4.0/libgo/runtime/go-main.c:54

goroutine 17 [runnable]:
stack trace unavailable
awilcox on gwyn [pts/10 Tue 12 7:30] ~: 

[awilfox]

GCC was configured as follows:

awilcox on gwyn [pts/10 Tue 12 7:32] ~: gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc64-foxkit-linux-musl/6.4.0/lto-wrapper
Target: powerpc64-foxkit-linux-musl
Configured with: /usr/src/packages/system/gcc/src/gcc-6.4.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --build=powerpc64-foxkit-linux-musl --host=powerpc64-foxkit-linux-musl --target=powerpc64-foxkit-linux-musl --with-pkgversion='Adelie 6.4.0' --with-bugurl=http://bts.adelielinux.org/ --enable-checking=release --disable-fixed-point --disable-libstdcxx-pch --disable-multilib --disable-werror --disable-symvers --enable-__cxa_atexit --enable-default-pie --enable-cloog-backend --enable-languages=c,c++,objc,java,go,fortran --with-abi=elfv2 --enable-secureplt --enable-decimal-float=no --disable-libquadmath --disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads --enable-tls --with-system-zlib --with-linker-hash-style=gnu
Thread model: posix
gcc version 6.4.0 (Adelie 6.4.0) 
awilcox on gwyn [pts/10 Tue 12 7:32] ~: 

[ianlancetaylor]

In the sense that I meant it, the program runs, it just crashes. This is not a pedantic objection. It strongly suggests that the problem is not the --with-abi configure option, but rather some bad interaction between the MUSL library and libgo.

I'm sorry I omitted the -g option. Can you show the output of

gccgo -g -o hello hello.go
./hello

Thanks.

[awilfox]

I've managed to actually build a gcc8 snapshot, dated 20190208. It seems to emit working code under C and C++. The Go runtime gives a lot more information, and it's really interesting.

awilcox on gwyn [pts/11 Tue 12 9:42] ~: experimental/gcc8/bin/gccgo -g -o hello hello.go
awilcox on gwyn [pts/11 Tue 12 9:43] ~: LD_LIBRARY_PATH=experimental/gcc8/lib64 ./hello 
fatal error: sigaction read failure

runtime stack:
runtime.dopanic
        ../../../libgo/go/runtime/panic.go:912
runtime.throw
        ../../../libgo/go/runtime/panic.go:819
runtime.throw
        ../../../libgo/go/runtime/panic.go:812
runtime.getsig
        ../../../libgo/go/runtime/signal_gccgo.go:117
runtime.initsig
        ../../../libgo/go/runtime/signal_unix.go:108
runtime.initsig
        ../../../libgo/go/runtime/signal_unix.go:83
runtime.mstartm0
        ../../../libgo/go/runtime/proc.go:1213
runtime.mstart1
        ../../../libgo/go/runtime/proc.go:1184
runtime_mstart
        ../../../libgo/runtime/proc.c:545

goroutine 1 [runnable]:
fatal error: unexpected signal during runtime execution
panic during panic
[signal SIGSEGV: segmentation violation code=1 addr=0 pc=1]

runtime stack:
runtime.dopanic
        ../../../libgo/go/runtime/panic.go:912
runtime.startpanic
        ../../../libgo/go/runtime/panic.go:869
runtime.throw
        ../../../libgo/go/runtime/panic.go:818
runtime.throw
        ../../../libgo/go/runtime/panic.go:812
runtime.sigpanic
        ../../../libgo/go/runtime/signal_unix.go:332
runtime.sighandler
        ../../../libgo/go/runtime/signal_sighandler.go:64
runtime.sigtrampgo
        ../../../libgo/go/runtime/signal_unix.go:312
runtime.sigtramp
        ../../../libgo/runtime/go-signal.c:54

        :0

        :0

[awilfox]

(If it matters, the GCC 6 toolchain with -g produced identical output as without -g.)