debug: breakpoints don't work when working with symlink

[hyangah]

Continuation of microsoft/vscode-go#2958 (lost during repo migration) and microsoft/vscode-go#1935. If we can't find a fix, we need to document this problem at least.

cc @suzmue @quoctruong

From microsoft/vscode-go#2958:

It is a continuation of an issue #1935

Unfortunately, the conversation there was locked to members only, so I had to open this card.

I have been able to reproduce the behavior (VSCode does not stop at breakpoints, while dlv itself does) for the symlinked GOPATH on two separate Ubuntu 19.10 installations, and I am pretty sure the issue is reproducible in other distros this way as well.

Set up to reproduce:

1. Install go via package manager (both apt and snap work, mainly tested with snap, version go1.13.5 linux/amd64)
2. Create a future GOPATH as ~/go
3. Add GOPATH to your ~/.bashrc:

export GOPATH=`builtin cd ~/go && pwd`
export PATH=$PATH:$GOPATH/bin

4. Create/clone a project folder in ~/go/src/github.com/<your_github_name>/<your_repo_name>
5. Symlink ~/go/src/github.com to ~/GitHub
6. Set up Go support for VSCode just as it is recommended in the guide, or follow the UI recommendations & install all the libraries it now wants
7. Create a trivial main.go to try out the breakpoints:

package main

import "fmt"

func main() {
	fmt.Println("Hello World!")
	i := 101
	fmt.Println(i)
}

Reproducing

• If you open ~/go/src/github.com/<your_github_name>/<your_repo_name> folder and set a breakpoint at i := 101, the execution would be successfully paused at it.
• However, if you open ~/GitHub/<your_github_name>/<your_repo_name> folder and set the breakpoint, it will never be hit.
  No launch configuration was created, all default - debug was in both cases launched just by a press of F5.

Unfortunately, I have not been able to take a look inside the debugger yet, but at least this reproduction scenario might be helpful

[suzmue]

Logs from reproducing this on darwin:

...
[15:47:50.706 UTC] LaunchRequest
[15:47:50.715 UTC] Using GOPATH: /Users/suzmue/go
[15:47:50.715 UTC] Using GOROOT: /Users/suzmue/sdk/go1.15.2
[15:47:50.716 UTC] Current working directory: /Users/suzmue/Github/suzmue/restart
...
[15:47:53.490 UTC] From client: setBreakpoints({"source":{"name":"main.go","path":"/Users/suzmue/Github/suzmue/restart/main.go"},"lines":[6],"breakpoints":[{"line":6}],"sourceModified":false})
[15:47:53.490 UTC] SetBreakPointsRequest
[15:47:53.872 UTC] All cleared
[15:47:53.872 UTC] Creating on: /Users/suzmue/Github/suzmue/restart/main.go:6
[15:47:53.873 UTC] Error on CreateBreakpoint: could not find file /Users/suzmue/Github/suzmue/restart/main.go
...

Delve does not attempt to resolve symlinks (delve#1808) so when the extension passes a path within ~/Github, it fails to set the breakpoint (since the files used to build the program were actually in ~/go/src/github.com). To fix this we probably need to resolve the path ourselves before passing to delve or use the delve config suggested in delve#1808 (config substitute-path <symlink-dir> <original-dir>). It also seems like passing a relative path to program instead of an absolute path could fix this problem as well.

[hyangah]

I think config substitute-path belongs to the dlv cli. (@polinasok can you please correct me if I am wrong). If true, that
implies this path resolution should be done on our side. Is it possible to swap with the resolved path from src/goDebugConfiguration.ts?

[polinasok]

Yes config command is part of the interactive dlv cli and is fully handled in the terminal frontend. I don't think we have a way of doing this interactively, do we? But we could support upfront session-long substitution via launch.json (like when config file is used with dlv). This would be similar to how we approach the functionality of (dlv) config max-string-len 100 with dlvLoadConfig.maxStringLen, which supplies values to the args of the RPC commands that we issue on variables and evaluate requests.

[gopherbot]

Change https://golang.org/cl/257204 mentions this issue: docs/debugging.md: document lack of symlink support

[suzmue]

We plan to address this issue by providing a user configuration to map directories to each other. This would allow users to specify to and the debug adapter would translate all paths that it sends to delve and receives from delve.

This will not attempt to resolve symlinked paths, but should make debugging more usable for users that are debugging symlinked directories.

[gopherbot]

Change https://golang.org/cl/270017 mentions this issue: src/debugAdapter: add substitutePath config for debugging

[gopherbot]

Change https://golang.org/cl/277961 mentions this issue: test: remove symlink tests for substitutePath

[hyangah]

@suzmue Do we need anything more to close this issue?