Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
awilfox opened this issue Feb 2, 2019 · 25 comments

Comments

@awilfox
Copy link

commented Feb 2, 2019

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.

@gopherbot gopherbot added this to the Gccgo milestone Feb 2, 2019

@bdragon28

This comment has been minimized.

Copy link

commented Feb 2, 2019

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

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 2, 2019

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

This comment has been minimized.

Copy link
Author

commented Feb 3, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Feb 5, 2019

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?

@andybons andybons changed the title gccgo doesn't seem to honour configure --with-abi gccgo: doesn't seem to honour configure --with-abi Feb 6, 2019

@awilfox

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

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

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Feb 12, 2019

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

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

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

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

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

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 12, 2019

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?

@awilfox

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

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.

@awilfox

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

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
@awilfox

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

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...

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 12, 2019

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.

@awilfox

This comment has been minimized.

Copy link
Author

commented Feb 13, 2019

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.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 13, 2019

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?

@awilfox

This comment has been minimized.

Copy link
Author

commented Feb 13, 2019

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.

@awilfox awilfox changed the title gccgo: doesn't seem to honour configure --with-abi gccgo: doesn't work on powerpc64 with kernel ucontext functions Feb 14, 2019

@awilfox

This comment has been minimized.

Copy link
Author

commented Mar 3, 2019

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.

@awilfox

This comment has been minimized.

Copy link
Author

commented Mar 3, 2019

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.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2019

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.

@laboger

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

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?

@awilfox

This comment has been minimized.

Copy link
Author

commented Apr 20, 2019

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.

@awilfox

This comment has been minimized.

Copy link
Author

commented Apr 20, 2019

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.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2019

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?

@awilfox

This comment has been minimized.

Copy link
Author

commented Apr 25, 2019

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.