gccgo: doesn't work on powerpc64 with kernel ucontext functions #30062
Comments
|
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. |
|
|
|
How exactly did you run the GCC configure script? What happens if you run |
andybons
added
WaitingForInfo
andybons
changed the title
|
No. |
|
GCC was configured as follows: |
ianlancetaylor
removed
the
WaitingForInfo
|
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 I'm sorry I omitted the Thanks. |
ianlancetaylor
added
the
WaitingForInfo
|
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. |
|
(If it matters, the GCC 6 toolchain with -g produced identical output as without -g.) |
ianlancetaylor
removed
the
WaitingForInfo
|
Thanks, that means that the call to |
|
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: Still investigating this. |
|
|
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... |
|
|
|
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 Does |
|
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 |
awilfox
changed the title
|
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: 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 The Defining This is, unfortunately, necessary. Right now Go is breaking the PowerPC ABI with its definition of Performing this change caused a runtime error: 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, 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 Simply defining If you patch in the |
|
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. |
mdempsky
added
the
WaitingForInfo
|
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.
The text was updated successfully, but these errors were encountered: