Closed awilfox closed 3 years ago
FreeBSD powerpc64 (which is BE only) is also moving towards ELFv2 and will likely be affected by the same issue.
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.
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.
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?
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] ~:
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] ~:
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.
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
(If it matters, the GCC 6 toolchain with -g produced identical output as without -g.)
Thanks, that means that the call to sigaction
at line 111 of signal_gccgo.go failed. That call should never fail. Can you run the program under the debugger to find out what happened?
The issue is that musl uses SIG34 internally, the same way glibc uses SIG32 and SIG33. Adding " || i == 34" to line 114 fixes this, and presents a different trace:
awilcox on gwyn [pts/11 Tue 12 14:48] ~: gcc8/bin/gccgo -g -o hello hello.go
awilcox on gwyn [pts/11 Tue 12 14:48] ~: LD_LIBRARY_PATH=gcc8/lib64 ./hello
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=1 addr=125464 pc=4532106540]
runtime stack:
main
../../../libgo/runtime/go-main.c:43
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
main
:0
goroutine 1 [running]:
fatal error: runtime: mcall function returned
panic during panic
goroutine 1 [running]:
runtime.dopanic
../../../libgo/go/runtime/panic.go:909
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_throw
../../../libgo/runtime/panic.c:13
runtime.mcall
../../../libgo/runtime/proc.c:358
runtime.systemstack
../../../libgo/go/runtime/stubs.go:66
runtime.main
../../../libgo/go/runtime/proc.go:172
Still investigating this.
Program received signal SIGSEGV, Segmentation fault.
0x000000010000152c in main (argc=-135155808, argv=0x0) at ../../../libgo/runtime/go-main.c:41
41 runtime_isarchive = false;
(gdb) bt full
#0 0x000000010000152c in main (argc=-135155808, argv=0x0) at ../../../libgo/runtime/go-main.c:41
No locals.
#1 0x0000000100001520 in 00000069.plt_call.os..import ()
No symbol table info available.
Backtrace stopped: frame did not save the PC
Something about this seems really weird. It seems to be falling apart when it calls into set/swapcontext; I almost wonder if it is a kernel bug in SYS_swapcontext...
swapcontext
is not a system call. It is implemented entirely by the C library. Perhaps there is some problem with the musl implementation, or at any rate some disagreement between its implementation and what libgo expects.
It is a system call on PowerPC. And the musl implementation is an external library which utilises the system call on PowerPC.
I will note that GCC Go works fine using SYS_swapcontext on 32-bit PowerPC; even on a 64-bit host, running the 32-bit code in compat mode works perfectly fine. This is why I am curious if there is a subtle issue in the 64-bit syscall.
Thanks, that is interesting. I was not aware that swapcontext
is a system call for 32-bit PPC. It looks like on 64-bit PPC glibc does it in user space, but on 32-bit it does a system call. I wonder why.
Does strace -f
show any interesting difference between the swapcontext
call when using glibc or when using musl?
I don't actually know of any current 32-bit PPC distributions that use glibc. I can install Debian Jessie or Gentoo on to my Power G4 (32-bit PPC workstation), but with my current work schedule that would probably not be doable for a few days.
64-bit glibc does, indeed, use user-space code instead of a system call. For that reason, swapcontext is not in the output of strace
of a GCC Go-generated binary compiled against glibc.
It is indeed related to the kernel ucontext syscalls. When using user-mode ucontext syscalls, GCC Go seems to work perfectly fine on 64-bit PowerPC.
I've found a few errors in GCC 8 Go that prevent compilation on PowerPC (32 and 64) during this; how does one file merge requests for GCC Go? Do I submit them on GCC Bugzilla, or is there a way to do it here? Thank you.
Okay, that is, GCC 6.4's Go works fine.
GCC 8.3's Go does not:
(gdb) run
Starting program: /usr/src/packages/system/gcc/src/build/gotools/go version
[New LWP 59835]
[New LWP 59836]
Thread 1 "go" received signal SIGSEGV, Segmentation fault.
runtime.notesleep (n=0x0) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/lock_futex.go:167
167 gp.m.blocked = false
(gdb) bt
#0 runtime.notesleep (n=0x0) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/lock_futex.go:167
#1 0x00003ffff740bf00 in runtime.stoplockedm () at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:2024
#2 0x00003ffff740cef4 in runtime.schedule () at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:2415
#3 0x00003ffff740d56c in runtime.goschedImpl (gp=gp@entry=0xc420001000) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:2556
#4 0x00003ffff740d5d4 in runtime.gopreempt_m (gp=0xc420001000) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:2584
#5 0x00003ffff6f806fc in runtime_mstart (arg=<optimized out>) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/runtime/proc.c:527
#6 0x0000000100065e5c in main (argc=<optimized out>, argv=0x3ffffffff088) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/runtime/go-main.c:59
#7 0x00003ffff7f3d820 in ?? () from /lib/ld-musl-powerpc64.so.1
#8 0x00003ffff7f3d89c in __libc_start_main () from /lib/ld-musl-powerpc64.so.1
#9 0x0000000100065ef0 in _start_c (p=<error reading variable: value has been optimized out>) at crt/crt1.c:18
#10 0x0000000100065ea8 in _start ()
(gdb) p gp
$1 = (.runtime.g *) 0x0
Going to try to debug this. Any hints would be appreciated.
The best way to submit patches for gccgo is as described at https://golang.org/doc/gccgo_contribute.html. Thanks.
Sorry, I don't know why you are seeing that segmentation fault in 8.3. I haven't had any trouble running tip gccgo on PPC64 or PPC64LE.
I'm sorry but I am not very familiar with how gccgo was set up to work with the runtime. I think your problem is because you are using musl and not glibc. I understand that gccgo needs to use header files when calling glibc functions but I don't know how those header files compare when using musl. If it works on Linux with glibc but not on musl then it seems that's where the problem must be?
Okay. We have a lot more detail for you now.
Using -Og
instead of -O2
, the crash changed signature:
Thread 1 "go" received signal SIGILL, Illegal instruction.
__stack_chk_fail () at src/env/__stack_chk_fail.c:17
17 src/env/__stack_chk_fail.c: No such file or directory.
(gdb) bt
#0 __stack_chk_fail () at src/env/__stack_chk_fail.c:17
#1 0x00003ffff73ddbd4 in runtime.futexsleep (addr=0x3ffff7f10f18 <runtime.m0+288>, addr@entry=0x0, ns=-1, ns@entry=0, val=0) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/os_linux.go:39
#2 0x00003ffff73efb8c in runtime.notesleep (n=0x0) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/lock_futex.go:163
#3 0x00003ffff740cd8c in runtime.stoplockedm () at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:2024
#4 0x00003ffff740dda4 in runtime.schedule () at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:2415
#5 0x00003ffff740e43c in runtime.goschedImpl (gp=gp@entry=0xc420001000) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:2556
#6 0x00003ffff740e4a4 in runtime.gopreempt_m (gp=0xc420001000) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:2584
#7 0x00003ffff6f4f7c8 in runtime_mstart (arg=<optimized out>) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/runtime/proc.c:527
#8 0x00000001000f5d64 in main (argc=<optimized out>, argv=0x3ffffffff0b8) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/runtime/go-main.c:59
#9 0x00003ffff7f3d000 in libc_start_main_stage2 (main=0x1000f5c60 <main>, argc=<optimized out>, argv=0x3ffffffff0b8) at src/env/__libc_start_main.c:94
#10 0x00003ffff7f3d07c in __libc_start_main (main=0x1000f5c60 <main>, argc=<optimized out>, argv=0x3ffffffff0b8) at src/env/__libc_start_main.c:85
#11 0x0000000100065ef0 in _start_c (p=<error reading variable: value has been optimized out>) at crt/crt1.c:18
#12 0x0000000100065ea8 in _start ()
The syscall
definition in go/runtime/stubs.go
is invalid; it declares syscall
as taking exactly six parameters. The call is variadic and therefore has different ABI properties. This causes the syscall itself to overwrite the stack guard and cause this crash. Defining syscall
as taking eight parameters (which "accidentally" causes it to have the same ABI properties as a variadic call) will make the futex call stop crashing (but raises segfaults in other components of the runtime).
Defining syscall
as variadic causes a build failure:
/usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/os_linux.go:65:64: error: ts escapes to heap, not allowed in runtime
futex(unsafe.Pointer(addr), _FUTEX_WAIT, val, unsafe.Pointer(&ts), nil, 0)
^
This is, unfortunately, necessary. Right now Go is breaking the PowerPC ABI with its definition of syscall
. I am very inexperienced with programming in Go, but reading the documentation on unsafe it appears that changing the signature of futex
so ts
is uintptr
, and casting as uintptr(unsafe.Pointer(&ts))
may be the correct solution.
Performing this change caused a runtime error:
Thread 1 "go" hit Breakpoint 1, 0x00003ffff6f4d3f4 in __go_runtime_error (i=6) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/runtime/go-runtime-error.c:62
62 {
(gdb) bt
#0 0x00003ffff6f4d3f4 in __go_runtime_error (i=6) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/runtime/go-runtime-error.c:62
#1 0x00003ffff741c248 in runtime.mallocgc (size=<optimized out>, typ=<optimized out>, needzero=<optimized out>) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/malloc.go:623
#2 0x00003ffff741d4d8 in runtime.newobject (typ=<optimized out>) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/malloc.go:873
#3 0x00003ffff73ddb70 in runtime.futex (addr=0x3ffff7f10f18 <runtime.m0+288>, op=<optimized out>, op@entry=0, val=<optimized out>, val@entry=0, ts=<optimized out>, ts@entry=0, val3=0, addr2=0x0)
at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/os_linux.go:17
#4 0x00003ffff73dde40 in runtime.futexsleep (ns=-1, val=0, addr=<optimized out>) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/os_linux.go:48
#5 runtime.futexsleep (addr=addr@entry=0x3ffff7f10f18 <runtime.m0+288>, ns=ns@entry=-1, val=0) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/os_linux.go:39
#6 0x00003ffff73efdcc in runtime.notesleep (n=0x3ffff7f10f18 <runtime.m0+288>) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/lock_futex.go:163
#7 0x00003ffff740cfcc in runtime.stoplockedm () at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:2024
#8 0x00003ffff740dfe4 in runtime.schedule () at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:2415
#9 0x00003ffff740e67c in runtime.goschedImpl (gp=gp@entry=0xc420001000) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:2556
#10 0x00003ffff740e6e4 in runtime.gopreempt_m (gp=0xc420001000) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:2584
#11 0x00003ffff6f4f9a8 in runtime_mstart (arg=<optimized out>) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/runtime/proc.c:527
#12 0x00000001000f5d64 in main (argc=<optimized out>, argv=0x3ffffffff0b8) at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/runtime/go-main.c:59
#13 0x00003ffff7f3d000 in libc_start_main_stage2 (main=0x1000f5c60 <main>, argc=<optimized out>, argv=0x3ffffffff0b8) at src/env/__libc_start_main.c:94
#14 0x00003ffff7f3d07c in __libc_start_main (main=0x1000f5c60 <main>, argc=<optimized out>, argv=0x3ffffffff0b8) at src/env/__libc_start_main.c:85
#15 0x0000000100065ef0 in _start_c (p=<error reading variable: value has been optimized out>) at crt/crt1.c:18
#16 0x0000000100065ea8 in _start ()
I will assume this is the reason for the build failure "error: ts escapes to heap, not allowed in runtime", and trying to "outsmart" the runtime in this way caused this failure.
golang/gofrontend@f3fb9bf is the reason GCC 6.4.0 Go works and GCC 8.3.0 Go does not. Before this change, runtime.futex
was implemented in C.
We definitely want to work with you to upstream a fix for this issue. However, it may be possible to attempt to revert this commit in our GCC package if you are not interested in supporting PPC64/musl.
The problem with the declaration of syscall
was fixed a couple of months ago by https://golang.org/cl/160700.
Simply defining syscall
as variadic in Go doesn't work, as variadic functions in Go are quite different from variadic functions in C.
If you patch in the syscall
part of https://golang.org/cl/160700 does that fix this problem, or is there further work required?
Yes, taking the syscall parts does solve this issue. Specifically, libgo/go/runtime/stubs.go, libgo/go/syscall/syscall_unix.go, and libgo/runtime/go-varargs.c.
Now there is another crash. This time it may be in the ucontext emulation, we will do some more debugging on our side.
unexpected fault address 70367333224448
fatal error: fault
[signal SIGSEGV: segmentation violation code=2 addr=70367333224448 pc=70367359159548]
goroutine 3 [running]:
runtime.dopanic
/usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/panic.go:909
runtime.throw
/usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/panic.go:819
runtime.throw
/usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/panic.go:812
runtime.sigpanic
/usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/signal_unix.go:355
runtime.sighandler
/usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/signal_sighandler.go:64
runtime.sigtrampgo
/usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/signal_unix.go:312
runtime.sigtramp
/usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/runtime/go-signal.c:54
runtime.kickoff
/usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:1139
created by runtime.SetFinalizer
/usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/mfinal.go:369 +1436
goroutine 1 [runnable, locked to thread]:
debug_dwarf..import
/usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/debug/dwarf/entry.go:101
goroutine 4 [syscall]:
goroutine in C code; stack unavailable
created by os_signal.os_signal..init0
/usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/os/signal/signal_unix.go:28 +48
Thread 3 "go" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 23883]
0x00003ffff7408cfc in runtime.kickoff () at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:1139
1139 func kickoff() {
(gdb) bt
#0 0x00003ffff7408cfc in runtime.kickoff () at /usr/src/packages/system/gcc/src/gcc-8.3.0/libgo/go/runtime/proc.go:1139
#1 0x00003ffff6497a44 in setcontext () from /lib/libucontext.so.0
#2 0x38a006a0380000f9 in ?? ()
Backtrace stopped: Cannot access memory at address 0x2c3f00004182002c
Timed out in state WaitingForInfo. Closing.
(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)
What version of Go are you using (
go version
)?(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?
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.