debug: allow to pass custom commands to debugger

[msaf1980]

Delve debugger has some commands, that not realized in interface.
Like config max-string-len for display large string and etc.
May be add a way to interact with debugger and pass commands ?

[hyangah]

@msaf1980 We hear you, and the issue100 and so on mention the possibility of extending the Debug Console beyond the basic expression evaluation. We decided to start with support for only call command now. We will consider to add more commands only when they make sense in VS Code's graphical UI.

Some subset of settings configurable with the config command in cli may be considered, but many of them will not scale well with the graphical UI that pulls out a lot more information automatically (e.g. vscode retrieves all variables in scope, so if there are many long strings or huge maps, starting with large limit will cause troubles). Graphical UI opens up different data presentation possibilities than using such fixed limits (e.g. in graphical UI, it's possible that we can implement autoloading of extra elements in large arrays and pagination).

FYI here is some configuration knobs corresponding to config max-string-len. https://github.com/golang/vscode-go/blob/master/docs/debugging.md#configuration. This is not dynamically adjustable and may change in the future as @polinasok and delve devs are currently revisiting the design choice around this setting.

An alternative approach I can think of is to utilize the --accept-multiclient flag: so, make vscode-go launch the headless dlv with the flag and from the integrated terminal, connect to the headless dlv using dlv connect to enable an extra traditional cli interface. But any config changes using config command are applied only in the session, so will not affect the VS Code debugger UI.

[polinasok]

@msaf1980 To adjust max string length, you can set dlvLoadConfig.maxStringLen attribute in launch.json. See discussion in go-delve/delve#2144 on the revisit of these settings in the new debug adapter for delve.

In general, we are limited by what functionality we can provide by the Debug Adapter Protocol. Typing commands in the Debug Console triggers an EvaluateRequest, whose return value is an anonymous variable. It is not designed to support commands with arbitrary return values. We would have to hack those into a fake string variable to display the results as a flat string and you would not get any of the interactive UI features. Also, delve backend does not have an API to accept text commands. So to pass those over to Delve we would either need to reimplement its command-line client in vscode or convince Delve devs to add a text interface, which is unlikely.

[polinasok]

@hyangah +1 to having a parallel CLI client. I think this will give us the best of both worlds.

[polinasok]

It's infeasible to implement the entire delve CLI, but we could consider special casing some config options since with launch.json we only give a way for the uses to set max-string-len and others once per session and not dynamically.

@msaf1980 Which specific settings would be most useful to you?

[polinasok]

If we allow setting config options via Debug Console, we would also need a way to print their values.

$ config -list
aliases                map[]
substitute-path        []
max-string-len         <not defined>
max-array-values       <not defined>
max-variable-recurse   <not defined>
disassemble-flavor     <not defined>
show-location-expr     false
source-list-line-color 34
source-list-line-count <not defined>
debug-info-directories [/usr/lib/debug/.build-id]

[kgfly]

@polinasok , in VS code C/C++ debugging. To pass a command to gdb, in debugger console, you can run "-exec command" to pass any (entire) gdb command to gdb.

Can VS code go do sth similar?

Thanks

[jpap]

It's infeasible to implement the entire delve CLI, but we could consider special casing some config options since with launch.json we only give a way for the uses to set max-string-len and others once per session and not dynamically.

@msaf1980 Which specific settings would be most useful to you?

My vote is for examinemem. My current workaround is to add a hex dump to the code, recompile, and run again, which can get cumbersome.

[polinasok]

@kgflying

@polinasok , in VS code C/C++ debugging. To pass a command to gdb, in debugger console, you can run "-exec command" to pass any (entire) gdb command to gdb.

Can VS code go do sth similar?

Dlv has a split client/server architecture. There is the server backend (what you run with dlv --headless). And then there are different frontend clients that you can connect to it. Vscode is one such client. Dlv terminal is another one. The commands that you are familiar with are supported by the dlv terminal client. It doesn't run when vscode client connects to a headless dlv backend. The server backend uses a different API. Abstraction- and effort-wise there is not a clearcut way to move the text command parsing logic into the backend. But we are keeping this option on the backburner (hence the still open satus of this issue).

At the same time, graphical clients like vscode and the underlying Debug Adapter Protocol have rich UIs, and should be able to support many equivalent features that dlv cli supports natively and with additional interactive features. We are currently migrating to a new dlv-dap adapter. It is part of the delve codebase and is written in Go, so addition of any new features should be easier in the future. We are open to feedback and community PRs.

[polinasok]

My vote is for examinemem. My current workaround is to add a hex dump to the code, recompile, and run again, which can get cumbersome.

Does ReadMemoryRequest sound like a proper equivalent? Upvote client-side support here.

[polinasok]

Update on the status of using dlv text commands.

The legacy adapter (enabled with "debugAdapter": "legacy") is on its way to deprecation in favor of the new dlv-dap adapter (enabled with "debugAdapter": "dlv-dap"). We have recently added a custom config command to it. It is similar to dlv's config command, but not identical. For now these are the supported settings.

> dlv config -list
stackTraceDepth	50
showGlobalVariables	false
showRegisters	false
hideSystemGoroutines	true
substitutePath	[]

This opens the door to additional configuration settings (dlv config newOption) as well as potentially additional commands (dlv someCommand).

This does not offer a way to update max-string-len because we are using a different approach with dlv-dap that adjusts max string length dynamically to take the guess work from the user (see #1318#issuecomment-904366663).

In addition, we have updated the headless dlv server to accept either legacy JSON-RPC clients or DAP clients. So if you really need access to the entire dlv's command-line, you can use an external headless server with --accept-multiclient and connect to it with both a VSCode client and a terminal client. It is possible to run them simultaneously, but attention is needed not to make any status-changing (from halted to running and back) commands from the parallel terminal client - see go-delve/delve#2322.

I am going to close this issue since the original request has been addressed and there is now a workaround for examinemem. @kgflying @jpap please file separate issues for any key capabilities you are still lacking.