cmd/link: nosplit stack overflow on AIX #29572
Comments
CC @Helflym |
@ianlancetaylor I wasn't sure if it was expected to work out of the box in this beta release or not. I'd be happy right now compiling the simplest of programs just to test the functionality out, even with limitations. |
Hi, This error is due to the fact that StackGuard is increased on AIX: This change appears in src/cmd/internal/objabi/zbootstrap.go, which is created by cmd/dist according to GOOS and GOARCH. Therefore, on linux/amd64, you will have stackGuardMultiplier = 1 while on aix/ppc64, I have stackGuardMultiplier = 2. @ianlancetaylo objabi.StackLimit is used in cmd/link even if a cross-compilation is requested. Therefore, its value depends on the host machine and not on the target one. Is it intended ? If not, is it possible to create a StackLimit value for all GOOS/GOARCH in src/cmd/internal/objabi/zstack.go or something like this ? Ps: Reducing stackGuardMultiplier to 1 is really hard if not impossible on AIX, because of syscalls using asmcgocall. |
stackGuardMultiplier was not intended to depend on the host. It was originally supposed to depend just on I think a better way to add extra stack space for AIX is to increase _StackSystem in src/runtime/stack.go. We do that already for other os/arch combinations. (It's an additive extra amount, not a multiplicative one.) |
I've added this GOOS dependence because I haven't found any other way to change the stacklimit. Values defined in src/runtime/stack.go aren't used inside cmd/link. Therefore, modify them won't fix these "nosplit stack overflow" which are triggered by cmd/link according to StackLimit value in src/cmd/internal/objabi/stack.go |
I see now, the stack overflow is because of the path up to It sounds like you would need to make StackGuard and stackGuardMultiplier variables instead of constants in objabi. Then modify them based on the target architecture (perhaps by making them functions that take the target arch as input?). The corresponding changes should be made in runtime/stack.go (but those can still be constants). Perhaps we can fix the underlying problem though. Reducing StackGuard space from 880 to 600 on linux/amd64 gets me the corresponding overflow trace:
I see two issues comparing this trace to the ppc64 one posted above. First, the ppc64 frames are generally bigger. That may be a difficult one to fix in general, not sure, but might be worth looking at a couple of the big ones to see if there's anything simple to fix. Second, there's a bunch of frames after sigaction that don't occur on linux (syscall3 + callees). Perhaps those can be wrapped in a systemstack call? |
The ppc64 frames are always bigger because 32 bits are reserved for each new frame (cf https://github.com/golang/go/blob/master/src/runtime/asm_ppc64x.h). All these checks/switches are actually done by asmcgocall. As far as I know stackcheck is only needed for nosplits in a "classic g stack". As functions called by asmcgocall are always on g0 or gsignal, should stackcheck stop when asmcgocall is found ? |
In this case the complaint seems to be about the call from |
Change https://golang.org/cl/157117 mentions this issue: |
What version of Go are you using (
go version
)?Installed with
go get golang.org/dl/go1.12beta1
Does this issue reproduce with the latest release?
It reproduces with the latest released Beta for 1.12.
What operating system and processor architecture are you using (
go env
)?I've put my Linux env below, but this also happens on Windows 10.
go env
OutputWhat did you do?
Created a simple
main.go
:then tried to build:
What did you expect to see?
I expected to see no direct output from the command on
stdout
andstderr
. I expected to see a binary on the file system created for the AIX environment and PowerPC architecture.What did you see instead?
A runtime traceback.
The text was updated successfully, but these errors were encountered: