[RFC] More complete multiprocess support in LLDB

First of all, I’m sorry for not replying earlier. I have to admit I’ve been defeated by Discourse once again, and somehow managed to make email notifications stop working.

Secondly, I’d like to thank you all for your feedback, and especially @labath for answering many of the questions directed at my proposal. In fact, he probably did it better than I would have been able to.

@JDevlieghere, to be honest, I was primarily hoping for ideas around implementing GDB-compatible multiprocess. I don’t want to discard other ideas outright but I still think a solution as close to GDB as possible is the way to go, as I’ll try to explain below.

@jingham, thank you for all your points. I agree that implementing multiprocess debugging on top of multiple connections would probably be easier. However, at this point we’re prepared to invest more effort for a harder but more future-proof solution.

I really do think that proceed with the GDB-compatible multiprocess extension approach is better.

I largely dislike the necessity of establishing multiple connections but I think @labath has covered that point very well. I’d really prefer to avoid having multiprocess support depend on special properties of transport to work. I’d like the multiprocess support to work on top on any primitive transport that isn’t capable of establishing multiple connections.

To achieve that, we need to multiplex packets over a single connection. And if we’re already multiplexing stuff, why not follow the de facto standard and use the gdb-remote protocol way of doing it?

Even if it’s more work and more code, I think we’ll have to eventually implement it anyway for compatibility with gdbserver. And then, I think it’s better to use it for lldb-server as well, rather than having to maintain and test two different solutions to the same problem.

We’ve already put some effort into improving compatibility with GDB in the past, including implementing a small subset of multiprocess extension. I think proceeding with furthering the protocol support is a natural continuation of that work.