Skip to content

Debugger: add support for client config #3245

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
vishal-wadhwa opened this issue Jun 5, 2021 · 3 comments · Fixed by #3301
Closed

Debugger: add support for client config #3245

vishal-wadhwa opened this issue Jun 5, 2021 · 3 comments · Fixed by #3301

Comments

@vishal-wadhwa
Copy link

vishal-wadhwa commented Jun 5, 2021

Add support for debugger configuration to customise parameters like max-string-len, max-variable-recurse and most importantly substitute-path.

What did you do? (required: The issue will be closed when not provided)

Tried to use vim-go's debugger client with a headless dlv instance running inside a docker container.

Steps:

  • :GoDebugConnect localhost:40000
  • Add a breakpoint in a project in which the the project path on the host is NOT the same as the path inside container.

What did you expect to happen?

I was expecting that the debugger will work out of the box or it will honour ~/.dlv/config.yml.

What happened instead?

Got this error:

vim-go: could not toggle breakpoint: could not find file /Users/vishal/work/<project-name>/<filename>.go

My understanding of this error is that vim-go passed the path of the file as it is to the debugger instance inside docker without performing any path substitutions that I had defined in ~/.dlv/config.yml. Since the debugger inside the container has a different project path, it could not resolve the file path it received and failed to set a breakpoint.

On checking vim-go's documentation further I could not find how I can configure vim-go to set any config that the delve client (or vscode-go) supports like substitute-path, etc.

Configuration (MUST fill this out):

vim-go version:

master (edd8c16)

vimrc you used to reproduce:

This shouldn't be required as the issue should be reproducible (and is more of a feature request). Will add if required.

vimrc

Vim version (first three lines from :version):

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled May  8 2021 16:50:19)
macOS version - x86_64
Included patches: 1-2483

Go version (go version):

go version go1.13.15 darwin/amd64

Go environment

go env Output:
GO111MODULE=""
GOARCH="amd64"
GOBIN="/Users/vishal/go/bin"
GOCACHE="/Users/vishal/Library/Caches/go-build"
GOENV="/Users/vishal/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/vishal/go"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/d_/4f4jn_8x51x3l5d8wn3fgqlr0000gn/T/go-build731624988=/tmp/go-build -gno-record-gcc-switches -fno-common"

gopls version

gopls version Output:
golang.org/x/tools/gopls v0.6.11
    golang.org/x/tools/[email protected] h1:7S2k0xuVYc3secjy2uz0n+fGYxGJU6gXsLOmQ/r1HoI=

dlv config

# Configuration file for the delve debugger.

# This is the default configuration file. Available options are provided, but disabled.
# Delete the leading hash mark to enable an item.

# Uncomment the following line and set your preferred ANSI foreground color
# for source line numbers in the (list) command (if unset, default is 34,
# dark blue) See https://en.wikipedia.org/wiki/ANSI_escape_code#3/4_bit
# Alternatively a string containing an escape sequence can also be used.
# source-list-line-color: 34

# Uncomment the following lines to change the colors used by syntax highlighting.
# source-list-keyword-color: "\x1b[0m"
# source-list-string-color: "\x1b[92m"
# source-list-number-color: "\x1b[0m"
# source-list-comment-color: "\x1b[95m"
# source-list-arrow-color: "\x1b[93m"

# Uncomment to change the number of lines printed above and below cursor when
# listing source code.
# source-list-line-count: 5

# Provided aliases will be added to the default aliases for a given command.
aliases:
  # command: ["alias1", "alias2"]

# Define sources path substitution rules. Can be used to rewrite a source path stored
# in program's debug information, if the sources were moved to a different place
# between compilation and debugging.
# Note that substitution rules will not be used for paths passed to "break" and "trace"
# commands.
substitute-path:
  - {from: /go/src/github.com/<org-name>, to: /Users/vishal/work}
  
# Maximum number of elements loaded from an array.
# max-array-values: 64

# Maximum loaded string length.
max-string-len: 128

# Output evaluation.
max-variable-recurse: 4

# Uncomment the following line to make the whatis command also print the DWARF location expression of its argument.
# show-location-expr: true

# Allow user to specify output syntax flavor of assembly, one of this list "intel"(default), "gnu", "go".
# disassemble-flavor: intel

# List of directories to use when searching for separate debug info files.
debug-info-directories: ["/usr/lib/debug/.build-id"]
@bhcleek
Copy link
Collaborator

bhcleek commented Jun 5, 2021

Delve will pick up the configuration file automatically; there's nothing for vim-go to do here. I'm not exactly sure how this works when using dlv connect; I suspect that the config file you're using needs to be on the remote side (e.g. in your container).

@vishal-wadhwa
Copy link
Author

vishal-wadhwa commented Jun 5, 2021

Hi, thank you for the quick reply.

I think this is more of a client feature.

A quick look into delve's code base shows that the client terminal is maintaining state and doing the path substitution from the config. Here

Even vscode-go's documentation for substitutePath here states that it is used by the debugee.

Moreover, it sort of makes sense because the debugger instance is capable of serving remote as well as local clients, so, it cannot keep this substitution mapping as it would not know which clients need and don't need substitution.

Also, I tried what you said. Copied my local config inside the container and commented out my local config. It's not working with vim-go. Even both local and remote dlv cli clients' ls command stopped working. :(


Correction:
The delve client is indeed keeping the substitution rules but it may not always be doing the actual substitution. It is passing the rules in rpc call to the server and doing the substitution locally as well (for display purposes).

@bhcleek
Copy link
Collaborator

bhcleek commented Jun 5, 2021

Thanks. It looks like delve does have support for this with its FindLocation RPC call. I'll see about adding support for that in vim-go soon.

@bhcleek bhcleek added this to the vim-go 1.26 milestone Jun 5, 2021
bhcleek added a commit to bhcleek/vim-go that referenced this issue Oct 9, 2021
Add g:go_debug_subtitutions and hook up their use to the debugger so
that binaries that are compiled at a different location than where the
local source exists can be debugged.

Closes fatih#3245
bhcleek added a commit to bhcleek/vim-go that referenced this issue Oct 9, 2021
Add g:go_debug_subtitution_paths and hook up their use to the debugger
so
that binaries that are compiled at a different location than where the
local source exists can be debugged.

Closes fatih#3245
bhcleek added a commit to bhcleek/vim-go that referenced this issue Oct 11, 2021
Add g:go_debug_subtitution_paths and hook up their use to the debugger
so
that binaries that are compiled at a different location than where the
local source exists can be debugged.

Closes fatih#3245
bhcleek added a commit to bhcleek/vim-go that referenced this issue Oct 11, 2021
Add g:go_debug_subtitution_paths and hook up their use to the debugger
so
that binaries that are compiled at a different location than where the
local source exists can be debugged.

Closes fatih#3245
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants