build debug golang

[Axis]

Hello everyone,

    I am new in golang community.

    I just want to build a debug golang to do better debug.

    But when I want to build debug golang using the following instructions

    "

     export BOOT_GO_GCFLAGS="-N -l"

     export BOOT_GO_LDFLAGS="-w"

      ./make.bash

    "

    golang just print a error message:

    "

          compile: cannot disable optimizations while compiling runtime

     "

    It confused me, dose anyone tell me how to build debug golang?

    Thanks in advance.

Yifeng

[Ian Lance Taylor]

You can't build a debugging version of the runtime package. Sorry.
You can build debugging versions of most other standard library
packages, but not the runtime package.

This doesn't mean that it is impossible to use a debugger, it just
means that it is harder.

Ian

[董⼀峰]

Thanks for replying.

So golang only supports debugging optimized golang runtime?

It is weird to me as a C++ developer.  （T.T）

Yifeng

[Ian Lance Taylor]

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.

> It is weird to me as a C++ developer. （T.T）

There are many differences between Go and C++.

Ian

[董⼀峰]

thanks

[jake...@gmail.com]

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)?

[Ian Lance Taylor]

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

[jake...@gmail.com]

Thanks Ian.

Makes sense now. I was scratching my brain to figure out possible ways that lack of optimization could cause actual failures.The Go team does an amazing job.