cmd/compile: document -trimpath

[gopherbot]

by chetan.hs:

Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What does 'go version' print?
go version go1.3.3 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. Build any go program with ldflags -s option. Ex: go build -ldflags="-s" foo
-o foo.out
2. Extract the strings from the resulting binary and check for the current username,
build path etc. Ex: strings foo.out | grep <current_username>

What happened?
  - The debug symbols are still present in the output binary.

What should have happened instead?
  - This information should have been stripped out from the output binary.

Please provide any additional information below.
  - This option used to work in go v1.1

[ianlancetaylor]

Comment 1:

The -s option does work, in the sense that it removes the debug info read by gdb.
Stripping the file name information means that stack traces and functions like
runtime.Caller do not work, meaning that basic packages like log do not work.  Doing
that amounts to a way to silently break Go programs.  See issue #6245.
What is the actual problem you are trying to solve?  The pack program used to have an
option to remove prefixes from file names, but we may have lost that feature when we
added the -pack option to gc and rewrote the pack program in Go.  Would restoring that
feature fix your problem?

Labels changed: added repo-main, release-none.

[gopherbot]

Comment 2 by czapkofan:

Quoting the original poster's comments from the original thread:
> I ship my binary to users and I use the -s option to strip out information like the
full path of my build environment, the home directory, unix username etc. I'm still
using go 1.1 specifically for this reason. I feel being able to strip this information
is important to anyone who is distributing their binaries to other people.
https://groups.google.com/d/msg/golang-nuts/d-t_CfWFxhQ/F83J-Oyde-AJ
>> A workaround is just to build in a VM with generic username and home directory.
> It's not just the username and home directory. The path for different packages are
also inserted which may leak some of the project names and internal package names.
https://groups.google.com/d/msg/golang-nuts/d-t_CfWFxhQ/esLu0TIndYMJ

[ianlancetaylor]

Comment 3:

If the actual problem is defined as "leaking project names and internal package names"
then I'm not particularly sympathetic.  If it were harmless, sure, but it is not.
I'm certainly open to compromise solutions that do not break runtime.Caller, which is
why I mentioned the old pack option.

[gopherbot]

Comment 4 by chetan.hs:

Thanks for updating this issue with my comments form the thread.
Yes, restoring the pack feature would solve my problem as long as it strips out $GOPATH
file prefixes. Leaking project/package names is not the biggest concern (although
preventing it is desirable).

[ianlancetaylor]

Comment 5:

In Go 1.2 the P option to pack was documented as
    [P prefix]
    The new option 'P' causes pack to remove the given prefix
    from file names in the line number information in object files
    that are already stored in or added to the archive.

Labels changed: added release-go1.5, removed release-none.

[gopherbot]

Comment 6 by czapkofan:

Sorry if that's not on topic, but just wanted to comment, that with regards to "leaking
project/package names", a "solution" could be probably an external "source code mangler"
(probably utilizing the AST tools).

[gopherbot]

Comment 7 by chetan.hs:

How is this pack tool supposed to work? I was trying it in go v1.2.2 but couldn't figure
out how it works.
$ go version
go version go1.2.2 linux/amd64
$ go tool pack -P $GOPATH pkg/linux_amd64/foo.a
pack: bad option `-'
> with regards to "leaking project/package names", a "solution" could be probably an
external "source code mangler"
Thanks for the suggestion. I'll check if any such tools exist.

[ianlancetaylor]

Comment 8:

The Go 1.2 pack program, unlike the Go 1.3 pack program, works like the Unix ar program.
 You need to write something like "go tool pack rP $GOPATH foo.a".