search

vadimcn / codelldb

A native debugger extension for VSCode based on LLDB
https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb
MIT License
2.61k stars 246 forks source link

Single adapter process to handle multiple debug sessions #531

Open nisargjhaveri opened 3 years ago

nisargjhaveri commented 3 years ago

When the debug adapter is launched externally with --multi-session, and debugServer points to that adapter, I've noticed significantly faster launch/attach times. One of my process takes ~50 seconds to attach, but on subsequent attach with this config, it takes ~5 seconds. This is a huge gain!

I belive this is because of some kind of caching at lldb/os level when the same process is used for the second lldb debug session. I've noticed similar trend (faster attach from second session onwards) when debugging from Xcode as well, and Xcode also used something called lldb-rpc-server which lives longer than individual debug sessions and likely works similarly to an debug adapter.

Can we make something similar available here? I don't think multi-session flag as is can be used, as it likely won't be able to support multiple simultaneous sessions. But I think it should be possible with some tweaks.

Thoughts? Suggestions?

vadimcn commented 3 years ago

It'd be neat, but someone needs to figure out how to integrate this with VSCode. For example, what should be the scope of lldb process caching,- per-launch config, per-workspace, per-window, or something else?

If you look at lldb API, it's possible to create multiple SBDebuggers, each with its own set of targets and processes. However, I don't know how well this works in practice. I believe that in CLI lldb, only one debugger object exists at a time, which means that such use would be completely off the tested path, with all that this implies. I would not be surprised if my own code, too, makes an assumption somewhere that there's only a single debugger instance alive at a time.

Then there's the issue of cached state. For example, the Python interpreter loads modules only once. If you use Python scripts for data visualization, right now any modifications are reflected in the new debug session. If we reuse the process, this will no longer be true and might trip people up. And so on.

In general, one must be a lot more careful about cleaning up resources when the program is to be used a "caching server" mode. In my experience, cached state management in applications always buggy, unless extensively tested in that scenario.

So... a lot of stuff to explore and to figure out, and I currently don't have much time for this sort of explorations.

vadimcn commented 3 years ago

When the debug adapter is launched externally with --multi-session, and debugServer points to that adapter

This is how I debug it, and you are welcome to use that mode too, as long as you keep in mind what I wrote above about cached state management.