cmd/compile: Missing debug_info section on binaries produced by go run

[dlsniper]

What version of Go are you using (go version)?

go version go1.10.1 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

GOHOSTARCH=amd64
GOHOSTOS=windows

What did you do?

go run -gcflags="all=-N -l" main.go

The contents of main.go file:

package main

import (
	"log"
	"net/http"
	"strings"
)

func indexHandler(w http.ResponseWriter, r *http.Request) {
	w.Write([]byte(`Hello world`))
	if strings.Contains(strings.ToLower(r.UserAgent()), "chrome") {
		w.Write([]byte(` from ` + r.UserAgent()))
	}
}

func main() {
	log.Println("starting server...")
	http.HandleFunc("/", indexHandler)
	log.Fatal(http.ListenAndServe(":8080", nil))
}

What did you expect to see?

I would expect the resulting binary to have the .debug_info section present.

What did you see instead?

The debug info is not present, which means that Delve will fail with decoding dwarf section info at offset 0x0: too short .

Using objdump -h binary.exe | grep -i debug_info also does not show any section present in the executable produced by go run but it's there for go build -gcflags="all=-N -l".

[cherrymui]

go run passes -s -w to the linker, which strips the debug info. I think this is intentional. go run is intended for just doing something quick.

[ianlancetaylor]

This is working as expected. If you want debug info, don't use go run.

[dlsniper]

I'm sorry but this is not expected.

I'm using Go for a while and I was confused by it.
With all people out there showing/running go run in examples, it stands to reason that they will wonder why they can't debug an app they are launching like this. Many may not know about go build or if they encounter a bug they may want to debug it using Delve and attach to process.

As a user experience, this is not something that a user will understand.

As such, I ask you to please reconsider this, as I don't see any arguments for stripping the debugging information in go run only, especially when I explicitly send to the tool -gcflags="all=-N -l". Thank you.

[ianlancetaylor]

I'm sorry, but very few people are going to try to debug an app launched using go run, because they have no easy access to the executable file. And I do not think it is unreasonable to expect people to know about go build.

[dlsniper]

Sorry for the late reply, I just noticed it. While I agree with you, on the other hand, there are efforts to actually make go run even more useful, see #22726. As such I don't understand why we can't have this change done. I don't understand how stripping the debugging information provides a massive speedup vs operating in the "default" mode of go build.

[polinasok]

Just ran into the same kind user confusion with go-delve/delve#2844. I agree that this is not well known and that users generally expect go run to be a shortcut for go build, followed by running the binary. I checked go help for both, and this discrepancy is unfortunately not highlighted.

[ianlancetaylor]

Improving the documentation sounds like a good idea.