/ go Public
runtime: reduce static stack guard size #51256
Issues related to the Go compiler and/or runtime.
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
What version of Go are you using (
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
What did you do?
In cmd/internal/objabi and runtime we have
stackGuardMultiplierDefault, which is normally 1 but set to 2 by cmd/dist if the
-Nwhen building the toolchain and the standard library at make.bash(bat/rc) time. The idea is that for a no-opt build where the functions consume more stack space, we double the stack guard to avoid nosplit overflow.
But I suspect most users who use
-N -lbuild do not build the toolchain and the standard library this way. It is more likely that one would build the toolchain normally but use
-gcflags=all="-N -l"on the command line (at least since the introduce of build cache and automatic rebuild of the standard library packages). This way,
stackGuardMultiplierDefaultis still 1. So we're effectively keeping
-N -lbuild work with the non-doubled stack guard, which sometimes is difficult.
What did you expect to see?
Have some way to double the stack guard with
-N -lbuild that is actually useful. I can think of a few possibilities:
-Nis specified. Requires
-Nto be used for all packages or nothing. And needs some magic way to set the value in the runtime and tell the linker.
double the stack guard if
-Nis specified when compiling the runtime. The runtime and the linker will use the doubled stack guard (needs the same magic way). When compiling other packages it may still use the smaller one, but it probably doesn't hurt (besides slightly more frequent stack copying).
-N -lto all packages and double the stack guard. Deprecate the direct use of
-Nno-op for a few more nosplit-heavy packages. It is already no-op for the runtime package. Maybe it can also apply to reflect and syscall. (I suspect most times the user who use
-Nis not debugging those packages)
Maybe there are other options.
-N -lbuild work with the non-doubled stack guard. Again, this is sometimes difficult.
The text was updated successfully, but these errors were encountered: