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

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

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

Comments

Projects
None yet
4 participants
@dlsniper
Copy link
Contributor

commented Apr 12, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Apr 12, 2018

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 comment has been minimized.

Copy link
Contributor

commented Apr 12, 2018

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

@dlsniper

This comment has been minimized.

Copy link
Contributor Author

commented Apr 13, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 25, 2018

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.