Dup of #14319, although that issue has gotten rather complicated.

Note that this is not a stack overflow in the compiler. It is the compiler reporting that the runtime does not guarantee enough stack space for this code to succeed.

runtime.typedslicecopy: nosplit stack overflow

It's a very unclear message, if situation is not a stack overflow.

runtime does not guarantee enough stack space for this code to succeed

Runtime can't allocate enough stack space? Is it not a stack overflow?

How to tune runtime parameters to fix it?

Try nudging 880 up to 912 on these three lines:

src/cmd/internal/obj/stack.go:  StackGuard  = 880*stackGuardMultiplier + StackSystem
src/runtime/stack.go:   _StackGuard = 880*sys.StackGuardMultiplier + _StackSystem
test/nosplit.go:                                        size += (880 - 128) - 128
test/nosplit.go:                                                        size += 880

This may cause other problems, and I am surprised it got as large as 880.
I was working on this CL https://go-review.googlesource.com/c/27511/ to reduce that number back when it was 720.

It is not a stack overflow in the compiler. It is the compiler reporting that when you try to run your program it may get a stack overflow at runtime.

I note that you may not care about compiling the runtime package itself with -N -l. If you first go install -pkgdir pkg runtime you will get the runtime package built normally. You should then be able to build the rest of your program with -N -l.

It is the compiler reporting that when you try to run your program it may get a stack overflow at runtime.

Is it a stack checker, like address sanitizer, yes?

If you first go install -pkgdir pkg runtime you will get the runtime package built normally.

Ok, thank you.

Comparing this to address sanitizer is somewhat misleading. Go stacks have unlimited size. This is implemented by a small prologue at each function which checks whether there is enough stack space available to run the function. If there is not, the entire stack is copied to a larger stack, and then the function continues.

Implementing this requires some functions that do not copy the stack: functions that implement stack coying, that handle signals, that implement cgo calls. Those functions are in the runtime package. The test for whether there is enough stack space available to run a function ensures that there is a small amount of stack space always available to run those runtime functions if necessary. When you compile with -N -l the compiler (really, the linker) is reporting that there are possible call stacks in the runtime package that may require more stack space than is guaranteed to be available. This only happens with -N -l because less optimization means that the functions need more stack space.

Thanks. It's interesting. It's not a sanitizer, really, but more similar to stack guards.
It's a pity, that a specific functions (or code blocks in separated files) can't be built with specific parameters, provided (or removed from the common parameters set) in the blocks.

What actual problem are you trying to solve?

I crossbuild people's go code with my own buildsystem, which executes go get/go build, and I need to implement debug mode for people, who want to debug under Linux/macos (and, maybe windows).
Building specific libraries (even go runtime) is possible, but not very convenient for me.
Disabling this options absolutely in typedslicecopy, sigtrampgo and cgocallback_gofunc (i.e., using "magic comment") could be a very good solution.

/cc @josharian @cherrymui @davecheney

Actually, closing in favor of #14319