I’m exploring what it would take to enable the VS Code debugging UI for julia, and I’ve got some high level design questions about both the current status of the debugger and future plans.
Are there any plans for a wire protocol for the debugger, so that one could control a given julia process that is running under the debugger from a second process? I’m thinking roughly something like this with a protocol like this.
Related to that question is one about threads. Ideally such a setup would have a separate thread running the process that is being debugged that receives and responds the debug wire protocol messages. This thread ideally could for example set a new breakpoint while the main thread that is running the user code is busy. This of course would require that Gallium is thread-safe, but I assume that is not the case right now, correct?
I have no plans to offer a protocol beyond the julia level API in Gallium proper. That said, there should be no problem implementing a separate protocol on top those APIs. In the future there will also likely be a separate process mode, which would allow the debugger and the debuggee to be in different address spaces. As it is, running any significant code while the debugger is running is somewhat icky.
That is essentially what I need for the VS Code integration. How would the debugger and the debuggee communicate? That would require a wire protocol of some sort, right? Any more thoughts you have how you intend to do this would really help me plan around this. Also, do you have any timeline in mind?
Can you elaborate? It is not clear to me what you mean with this sentence.
What I mean by this is that I’ll add a mode that behaves like a regular debugger where the debuggee will be paused while the debugger is running. The actual pausing happens by OS-specific system calls. As far as timeline goes, all the code is basically there. I’m already using Gallium do debug C applications in this mode. However, there’s some more work to be done to clean that up, esp. around expression evaluation (since the debugger and the debuggee won’t be sharing data structures any more). I can’t give a firm timeline, but I’d say probably within 2-3 months.
Hitting a breakpoint while in the debugger will probably crash at the moment. There are some assumptions that the event loop doesn’t run. If you get unlucky and run the gc at the wrong time, things will crash, etc. The current state of affairs is transitionary until we get a full out-of-process debugger (just to be clear this is independent of the UI to interact with the debugger, which can behave completely independently of whether or not it’s in the same address space).
That all sounds very promising, looking forward to it!
Let me just describe how I imagine this would work in the end for VS Code, just so that you can check whether that squares with your design. In a typical debug session we would have three processes running. Process 1 is VS Code, i.e. all the UI. Process 2 is what is called a “debug adapter” in VS Code parlance. It would be written in julia. The debug adapter communicates with VS Code via the Microsoft Debug Protocol via STDIN and STDOUT. This debug adapter would use the new API in Gallium that allows debugging of other julia processes. Process 3 would be a julia instance that runs the user code and is controlled via the Gallium API from process 2.
I assume the new Gallium API might have things like this?
session = new_debug_session(path_to_julia_script)
setbreakpoints(session, breakpoints)
register_breakpoint_callback(session, do_something_on_breakpoint)
run(session)
enter_messageloop_that_processes_ms_debug_protocol_messages(session) #This is not a Gallium API
This is obviously pseudo-code, but roughly something like that?
Also, if you have an example of say how to start a julia script out-of-process in debug mode, set a breakpoint, run and break, could you point me to it? I think it might make sense to try to get that running with VS Code, even before all the say expression eval etc. is done, just to make sure the design of the API will work with the VS Code requirements.
Oh, one more thing: What about remote debugging? Would this also allow me to debug a julia process on a different machine? That would be really handy for cluster situations.
The actual API isn’t complete yet, so I can’t point you to an example (If you really want you can look at Arsenic.jl to see the C/C++ version, but it’s still a bit of a mess at the moment).
Remote debugging should be fairly simple. You’d just need an extra process:
VS Code <— VS Code protocol —> Debug Adapter ← Regular Julia RPC → Gallium.jl debugger ← ptrace, etc. → debuggee