On Fri, Jul 9, 2021 at 8:33 AM jake...@gmail.com <jake6...@gmail.com> wrote: > > On Thursday, July 8, 2021 at 11:45:19 PM UTC-4 Ian Lance Taylor wrote: >> >> On Thu, Jul 8, 2021 at 8:41 PM 董⼀峰 <dongyif...@bytedance.com> wrote: >> > >> > Thanks for replying. >> > So golang only supports debugging optimized golang runtime? >> >> Well, Go requires that the runtime package be built with optimization >> (when using the gc compiler, which is the default). So, yes, when >> running runtime code under the debugger you will be looking at >> optimized code. > > > Is this just to keep people from accidentally making a slow version of the > runtime, or is there an actual technical reason why it would not work? If > the check were removed > (https://github.com/golang/go/blob/ef57834360cf69f2e8b52b32c7a05d96bf6bbba7/src/cmd/compile/internal/base/flag.go#L226) > is there any reason to believe that the runtime would not function correctly > (albeit slowly)?
Yes, there are cases that will fail if the runtime is compiled without optimization. The Go compiler and runtime cooperate to ensure that there is a certain amount of stack space available at all times. Certain parts of the runtime can't copy the stack for various reasons (these functions are marked with "//go:nosplit" in the runtime Go code and with NOSPLIT in the runtime assembly code). Those parts of the runtime are constrained to run within the amount of stack space that is always available. When the runtime is compiled without optimization, functions use more stack space, and in some cases there are sequences of nosplit function calls that run over the amount of stack space they have available. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXw6Z-VZELOoAiSLgEnFsMWakOr-TEHC4YtWHbRqsAUaw%40mail.gmail.com.
