CC @randall77

The failure here is "nosplit stack check too deep" reported by the linker (https://go.googlesource.com/go/+/refs/heads/master/src/cmd/link/internal/ld/lib.go#2295). When not using -gcflags=-l these simple functions are inlined and the stack check is not too deep. With -gcflags=-l you run into an intentional limit in the linker.

We can increase the stack limit if there are real programs with a stack check that deep. But I'm not sure we should increase it for a test program. Any limit we set can be easily exceeded by any test program. Is it important for the test to have such a deep call graph? Does that correspond to real programs?

It is a case of "It used to work it doesn't anymore"; that's was caught by a real project that is currently used, the real world value of this specific case is discutable.

I wrote panic in panicparse to test edge cases. The test case stack_cut_off_named is to ensure that stack elision works both when inlining occurs and doesn't. If I recall correctly, the reason it's so deep is that on the previous optimizer it used to optimize a depth of 10 functions at a time, leaving ~200 frames in the stack so I could test elision even when the optimizer is enabled.

My primary concern is that it only fails when running with coverage or when disabling the inliner to debug something. Otherwise it works just fine.

This can be surprising to developers when they disable optimizations to debug something more easily and the program stops compiling. I'd prefer if the behavior was consistent. I would suspect this would risk happening mostly in generated code as I wouldn't expect humans to naturally such deep recursive code.

As I noted in my report, it does fail when using coverage but I failed to extract a simplified repro case, you can reproduce locally with:

git clone https://github.com/maruel/panicparse
cd panicparse
go test -covermode=count ./cmd/panic

The fact that this occurs with go test -covermode=(atomic|count|set) is much more material to me than with -gcflags -l.

I figured out a reduced repro case for go test -covermode=set :

• main.go.txt
• main_test.go.txt

Observations:

• go test and go test -race passes, but go test -covermode=set fails to link.
• It doesn't repro if the code is all in main_test.go.
• For the function pointer, using recurse2000 works, but func() { recurse2000() } fails.
• It doesn't matter if the leaf function do nothing.