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

cmd/internal/obj: stackGuardMultiplier is wrong for a cross-compiler #13431

Open
rrh opened this issue Nov 30, 2015 · 3 comments
Open

cmd/internal/obj: stackGuardMultiplier is wrong for a cross-compiler #13431

rrh opened this issue Nov 30, 2015 · 3 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.
Milestone

Comments

@rrh
Copy link

rrh commented Nov 30, 2015

This issue is similar to that reported in #12764 except that GOOS=linux and i'm running on a fairly pristine image of macosx El Capitan.

when cross compiling to GOOS=linux on macosx El Capitan using go 1.5.1 I get a nosplit stack overflow. It happens in the link step, AFAICT from using the -v option to go build.

runtime.cgocallbackg: nosplit stack overflow
504 assumed on entry to runtime.cgocallbackg (nosplit)
416 after runtime.cgocallbackg (nosplit) uses 88
408 on entry to runtime.exitsyscall (nosplit)
288 after runtime.exitsyscall (nosplit) uses 120
280 on entry to runtime.exitsyscallfast (nosplit)
120 after runtime.exitsyscallfast (nosplit) uses 160
112 on entry to runtime.writebarrierptr (nosplit)
64 after runtime.writebarrierptr (nosplit) uses 48
56 on entry to runtime.writebarrierptr_nostore1 (nosplit)
0 after runtime.writebarrierptr_nostore1 (nosplit) uses 56
-8 on entry to runtime.acquirem (nosplit)
reflect.typelinks: nosplit stack overflow
504 assumed on entry to reflect.typelinks (nosplit)
352 after reflect.typelinks (nosplit) uses 152
344 on entry to runtime.typedmemmove (nosplit)
320 after runtime.typedmemmove (nosplit) uses 24
312 on entry to runtime.heapBitsBulkBarrier (nosplit)
192 after runtime.heapBitsBulkBarrier (nosplit) uses 120
184 on entry to runtime.throw (nosplit)
160 after runtime.throw (nosplit) uses 24
152 on entry to runtime.dopanic (nosplit)
72 after runtime.dopanic (nosplit) uses 80
64 on entry to runtime.getcallerpc (nosplit)
56 after runtime.getcallerpc (nosplit) uses 8
48 on entry to runtime.nextBarrierPC (nosplit)
8 after runtime.nextBarrierPC (nosplit) uses 40
0 on entry to runtime.panicindex
-8 on entry to runtime.morestack (nosplit)
runtime.cgocallback_gofunc: nosplit stack overflow
504 assumed on entry to runtime.cgocallback_gofunc (nosplit)
496 after runtime.cgocallback_gofunc (nosplit) uses 8
488 on entry to runtime.cgocallbackg (nosplit)
400 after runtime.cgocallbackg (nosplit) uses 88
392 on entry to runtime.exitsyscall (nosplit)
272 after runtime.exitsyscall (nosplit) uses 120
264 on entry to runtime.exitsyscallfast (nosplit)
104 after runtime.exitsyscallfast (nosplit) uses 160
96 on entry to runtime.writebarrierptr (nosplit)
48 after runtime.writebarrierptr (nosplit) uses 48
40 on entry to runtime.writebarrierptr_nostore1 (nosplit)
-16 after runtime.writebarrierptr_nostore1 (nosplit) uses 56

@ianlancetaylor
Copy link
Contributor

Copying reply from #12764:

The reflect.typelinks issue is fixed on tip by https://golang.org/cl/16932.

@rrh: are you compiling with -N? The stack sizes you are reporting are too large. The values I see are

cgocallbackg 88
exitsyscall 32
exitsyscallfast 88
writebarrierptr 40
writebarrierptr_nostore1 48

@rrh
Copy link
Author

rrh commented Nov 30, 2015

I was using the -N flag. If I don't use it, the problem goes away.

@rrh rrh closed this as completed Nov 30, 2015
@ianlancetaylor ianlancetaylor changed the title no split stack overflow error on macosx when cross compile to linux during cmd/link cmd/internal/obj: stackGuardMultiplier is wrong for a cross-compiler Dec 1, 2015
@ianlancetaylor
Copy link
Contributor

cmd/dist creates stackGuardMultiplier based on whether the code is being built with -N. The value is fixed in cmd/internal/obj when cmd/dist is run. However, if you later wind up building a cross-compiler, then that cross-compiler should use a value of stackGuardMultiplier that corresponds to whether -N is being used to build a cross-compiler, not to the value used when the original toolchain was built.

@ianlancetaylor ianlancetaylor reopened this Dec 1, 2015
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Dec 1, 2015
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
None yet
Development

No branches or pull requests

3 participants