cmd/dist, cmd/internal/objabi, runtime: stackGuardMultiplierDefault is not useful #51256
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
What version of Go are you using (
go version
)?tip (eaf0405)
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?darwin/amd64
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 theGO_GCFLAGS
includes-N
when 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 -l
build 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,stackGuardMultiplierDefault
is still 1. So we're effectively keeping-N -l
build 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 -l
build that is actually useful. I can think of a few possibilities:-N
is specified. Requires-N
to 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-N
is 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 -l
to all packages and double the stack guard. Deprecate the direct use of-N -l
.-N
no-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-N
is not debugging those packages)Maybe there are other options.
Or, drop
stackGuardMultiplierDefault
and keep-N -l
build work with the non-doubled stack guard. Again, this is sometimes difficult.cc @aclements
The text was updated successfully, but these errors were encountered: