Comment 1:

I think filenames for stuff in TMPPATH, like _testmain.go, could be causing this. I
think you'll have the same problem with cgo apps. Not ideal.

Comment 2:

TMPDIR, not TMPPPATH.

Comment 3:

We can mangle the archives using go pack P to strip those paths.

Status changed to Accepted.

Comment 4:

http://golang.org/cl/6357064/
fixing the problem for cgo binaries is not as easy and I'm looking into it.

Comment 5:

This issue was closed by revision df623d0.

Status changed to Fixed.

Comment 6:

Does this fix it for cgo binaries? If not, maybe we should open another issue?

Comment 7:

it won't fix cgo binaries, and in fact, i doubt we can fix it completely.
for one thing, we pass -g to gcc, and gcc will surely embed the full path
to source file in the object files.
free free to open an issue for it though.

Comment 8:

GCC supports changing the path names used in the debug info, for situations like this. 
See the -fdebug-prefix-map option.
(I don't know if there are other problems here.)

Comment 9:

thanks iant, i will try to see if we can build identical cgo binaries for the same
source code.

Comment 10:

It might also be interesting to look at how Fedora works with debuginfos. You can build
an RPM almost anywhere, but when you install the debuginfo RPM, the source always goes
into /usr/src/whatever and you can set breakpoints accordingly.
It would be nice it Go worked with this scheme. I think it mostly will, but cgo has the
interesting property that some of the source that gets compiled into the binary only
exists in the work directory and gets deleted. I haven't debugged a cgo binary recently,
so I'm not sure what will happen with stack frames associated with this non-existent
code?