Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
dlsniper opened this issue Apr 12, 2018 · 7 comments
Closed

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

dlsniper opened this issue Apr 12, 2018 · 7 comments
Labels
FrozenDueToAge

Comments

@dlsniper
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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

@dlsniper
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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.

@golang golang locked and limited conversation to collaborators Apr 25, 2019
@polinasok
Copy link

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
Copy link
Contributor

Improving the documentation sounds like a good idea.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@dlsniper @ianlancetaylor @gopherbot @cherrymui @polinasok