cmd/link: delete source file path info in panic‘s stack trace for production releases

[johnjaylward]

see #6819 for original discussion.

Using paths relative to GOROOT or GOPATH seems reasonable. Some benefits are:

• Developer working directory would not be shown in production
• Paths in stack traces would be more succinct, showing only the relevant parts of the path
• Stack traces make sense across users and dev environments

[ianlancetaylor]

Have you tried using GOROOT_FINAL? See the docs at https://golang.org/cmd/go/#hdr-Environment_variables .

[johnjaylward]

I don't have GOROOT set currently. Is there a better doc on how to use both GOROOT and GOROOT_FINAL than that link? I'm unsure on how changing the values will affect my build environment or in what cases it will be used.

Also, if GO is only installed in my user directory, it doesn't look like this will help at all.

[ianlancetaylor]

There is not a better doc, no. You should not have GOROOT set. Just set GOROOT_FINAL and see what happens.

[johnjaylward]

$ cat release.sh
#!/bin/bash
export GOROOT_FINAL=/usr/local/Cellar/go/1.5.1/libexec

GOOS=darwin GOARCH=amd64 go build -o execOSX

$ ./execOSX
panic: WOW

goroutine 1 [running]:
main.main()
    /Users/me/git/go_apps/src/test/main.go:24 +0x65

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/Cellar/go/1.5.1/libexec/src/runtime/asm_amd64.s:1696 +0x1

It still shows my user path. It doesn't appear to accomplish what I was looking for.

[minux]

You should set GOROOT_FINAL to you want GOROOT to be in the executable, e.g. /usr/local/go.

[johnjaylward]

Setting the variable doesn't appear to do anything.

I can set it to /usr/local/go or /dev/null and my output is the same as being unset.

[minux]

Setting GOROOT_FINAL will be effective during go build for Go 1.6 and above. For older versions, you will need to rebuild Go with GOROOT_FINAL set.

[ianlancetaylor]

Closing as GOROOT_FINAL does seem to work in Go 1.6, and we aren't going to change this for Go 1.5.

[rsc]

As I understood @jonjaylward's report, specifically this stack trace:

goroutine 1 [running]:
main.main()
    /Users/me/git/go_apps/src/test/main.go:24 +0x65

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/Cellar/go/1.5.1/libexec/src/runtime/asm_amd64.s:1696 +0x1

I believe the objection is to seeing /Users/me/git/go_apps, not to /usr/local/Cellar/go/1.5.1/libexec. (Please correct me if I am wrong.)

The GOROOT_FINAL variable would change /usr/local/Cellar/go/1.5.1/libexec to something else, but it has no effect on code in GOPATH, like /Users/me/git/go_apps/....

As for the request to hide GOPATH in the source file information, we won't remove that by default. It's actually incredibly useful, even in production, to see the full path used to build the software. I certainly want to preserve that.

However, if your local setup is such that removing the GOPATH prefix makes sense, the thing to do is to compile with

go build -gcflags=-trimpath=$GOPATH -asmflags=-trimpath=$GOPATH

That would turn the above stack trace into:

goroutine 1 [running]:
main.main()
    src/test/main.go:24 +0x65

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/Cellar/go/1.5.1/libexec/src/runtime/asm_amd64.s:1696 +0x1

Given this solution I don't think we need to reopen the issue. But I'm happy to do so if I misunderstood the request.

[johnjaylward]

That solution is perfect and solves my issue. I was more concerned about the GOPATH than the GOROOT.

Can I pass multiple values to the trimpath in order to also trim both GOPATH and GOROOT if so desired?

[rsc]

For now you can only trim one prefix. We could plausibly make -trimpath take a list for Go 1.7. If that's useful to you please file a new issue. Thanks.