-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Debug adapter protocol support #574
Conversation
I think that requests I have already implemented are sufficient to build a starter-level debug integration. Maybe Now the main task is to think about the way DAP client is built into the editor, maybe this PR will need to wait for some stuff like vars or stack trace components. Helix needs a way to specify implementation-specific arguments (mainly for |
By the way are you on Matrix? If not, feel free to join the development channel so we can discuss :) |
Yeah I think we'll end up with something similar to the LSP config But there will also be a section to add different run types: I imagine we'd end up visualizing these in a picker.
|
Note that delve requires the most config, here's lldb: https://github.com/emacs-lsp/dap-mode/blob/master/dap-lldb.el I think delve is a good start though, and it's also the one I'll probably end up using the most (besides lldb). |
port_format: &str, | ||
id: usize, | ||
) -> Result<Self> { | ||
let port = Self::get_port().await.unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might have race condition in really rare situation (like lack of ports which might increase the probability):
- We acquired ephemeral port from OS
- Another process took it
- Debug adapter fails to start because port is acquired by other process.
Part of LLDB integration
Only report present features now
I could not get one from codelldb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like there's an off-by-one error when calculating cursor position returned from the debug server; hitting next always stops one character after the beginning of a variable. I have still not gone through the code completely, testing out the client first. Some kind of feedback on the current state of the debugger would also be nice (probably in the status line).
(We might want to include gitignored files to the path completion, used by the binary template for example since build directories are usually ignored.)
Yeah DAP uses 0-indexing by default, I think there's some missing conversions -- I changed up breakpoint tracking quite a lot over the last few commits. |
pub caps: Option<DebuggerCapabilities>, | ||
// thread_id -> frames | ||
pub stack_frames: HashMap<ThreadId, Vec<StackFrame>>, | ||
pub thread_states: HashMap<ThreadId, String>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should thread_states
map to an enum ? It seems like both the state and reason for the state change is stored here ("running", reason
from StoppedEvent
, etc).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be an enum if we hand an Other
variant for it, the specification allows for custom reasons:
reason: 'started' | 'exited' | string;
if cx.editor.debugger.is_some() { | ||
cx.editor | ||
.set_error("Debugger is already running".to_string()); | ||
return; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
editor.set_error(...); return;
is becoming a common enough pattern across commands so much that I think it's better to have commands return a Result, similar to typable commands and handle setting the error in a single place. Better off as a separate PR though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been thinking about this but I'm not sure. DAP/LSP commands need error handling, but most built in commands don't. I guess it would be nice for consistency?
Co-authored-by: Gokul Soumya <gokulps15@gmail.com>
}) | ||
} | ||
|
||
pub fn dap_step_in(cx: &mut Context) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
step_in
, step_out
, next
, etc all seem to share most of the code, differing only in the let request = debugger.step_in()
part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not much we can do here since the future types are all different :/ only thing I can think of is a macro to generate these
What work does it require to get this into master? Probably gdb and docs only, but not sure. |
Yeah I was holding back on merging It's mostly ready for an initial merge, I rewrote all the UI components and was working on a tree style viewer for the variables but I got distracted with some other helix tickets. I'll release 0.6 tomorrow then merge this so that we can work in smaller follow-up PRs. |
Well, so no work really required on this now? Then it should be easier: merge this PR, but don't close the issue. Move TODO list there and it's the debug roadmap now! |
Finally merged this! There's a bunch of work left to do, but it's easier if we don't have to maintain a separate branch. |
6 month PR :) Need to integrate gdb and then many other tasks will get unlocked |
Is there a reason you went with lldb-vscode instead of vscode-lldb? I ask because the former seems newer and only supported on Darwin? |
lldb-vscode works fine for me on Linux, it came together with the
|
It's a bit funny, earlier in the week and earlier in the day, this misnomer repo (github: lanza/lldb-vscode) came up much higher when searching for lldb-vscode than the lldb-vscode in lldb... . Of course after dozens of searches today, it's buried under vague but clear links to the official lldb version. Anyway, my mistake, lldb-vscode definitely seems easier. Very nice to have rust debugging just work out of box as soon as helix could see lldb! Great feature, thanks @sh7dm ! |
Does anyone have any guides to getting lldb-vscode working on macOS? I'm not finding many resources |
As stated in the wiki:
Hence, you just need to install
LLVM comes with lldb-vscode bundled, but for it to work you have to add the In fact,
|
Fixes #505.
/cc @archseer
Current state: an initial implementation of DAP with some types, editor connection. To test DAP client:
go build -gcflags '-N -l' main.go
to build binary with readable variables or use:dbg source main.go
for Go.2.1.
gcc main.c -o main -O0 -g
for C program3. Start up Delve (chosen as a monolithic DAP+debugger in one binary) on port 7777:dlv dap -l 127.0.0.1:7777
3.1. Or lldb:
lldb-vscode -p 7777
tcp_process
transport will find free port and start debug adapter itself.cargo run --example dap-dlv
ordap-lldb
Editor integration works with Go, C/C++ and Rust programs at the moment.
Just enter directory containingNow you need to specify target manually, seemain.go
/main
(build output)/target/debug/rustdebug
for Rust and work with it.languages.toml
In editor I currently use example attached as a zip.
godebug.zip
TODO:
Not stdio. So,Transport
must be able to use TCP sockets and the lifecycle of debug adaptersattach
stopped
eventpause
,step
,restart
,eval
restart
supportsRestartRequest
eval
breakpoint
eventprogress*
eventsoutput
event's data can be recorded as wellis_running
)supportsTerminateRequest
eval
(after commpletions for eval are done)Middle clickRight click + Alt opens the prompt for editing conditionTried sending event into a closed channel
for eventslaunch
andattach
args, maybe some debug adapters' quirks.dlv dap
Local ``languages.toml` for Node:
Adjust path to extension in VSCode (or location where you unpacked the extension manually).