Rules_go: Missing external sources when debugging with dlv

[prestonvanloon]

To reproduce:
1) Have some bazel project with an external library provided by go_repository.
1) Build with bazel build -c dbg //program:main
1) Execute dlv exec bazel-bin/program/linux_amd64_debug/main
1) Set a breakpoint in the external library b github.com/abc/lib.(*Foo).Bar
1) Enter c to continue the execution until the breakpoint is hit
1) List the current source code with ls and see Command failed: open external/github.com/abc/lib/foo.go: no such file or directory

Is there any workaround besides not using bazel to build the debug binary?

[jayconrod]

It doesn't seem like we're stripping directory prefixes correctly at the moment. I think there are basically four cases here:

• Static files in the main workspace: these should work.
• Generated files in the main workspace: these should work.
• Files in the standard library. These do not work because the paths contain the string GOROOT, e.g., ./GOROOT/src/internal/cpu/cpu.go.
• Files in external repositories. These do not work because their path is relative to the execroot, not the workspace root, e.g., ./external/com_github_pkg_errors/stack.go

[devshorts]

Is there any progress on this? This is pretty frustrating

[dragonsinth]

I noticed the whole external/com_github_pkg_errors/stack.go source path formulation as we started building binaries in bazel and noticed that the stack traces differ now. Is that the intended source path for external go files over something like github.com/pkg/errors/stack.go?

[danny-skydio]

Something that works for me:

1. Build with bazel build -c dbg //program:main
2. Execute dlv exec bazel-bin/program/linux_amd64_debug/main
3. Map external/ path config substitute-path external/ /path/to/workspace-name/bazel-workspace-name/external/
4. Map GOROOT/ path config substitute-path external/ /path/to/workspace-name/bazel-workspace-name/external/go_sdk/

I put in an absolute path, but that's just out of convenience.