[lldb-dev] Same-Process Debugging

[Greg Clayton]

Right now NativeProcessProtocol and NativeThreadProtocol are for debugging other processes. We also want the ability to just look at other processes without debugging them (like a "sample" command that would start and stop a process and be able to look at it, backtrace it, but do nothing more than suspend and resume it. We could build this ability into NativeProcessProtocol and NativeThreadProtocol, but we currently assume that NativeProcessProtocol and NativeThreadProtocol will attach to and debug this other process. 

The lldb_private::Host layer can do "host" kind of things, so there could be functions added to the host layer if you want to inspect the current process that contains LLDB.

More comments below.

> On Jul 10, 2014, at 11:40 AM, Russell Harmon <eatnumber1 at google.com> wrote:
> 
> I've been looking into better leveraging LLDB for debugging it's own process, effectively allowing you to inspect your own program programmatically with a debugger-centric view.
> 
> I already built a functioning API for introspecting C programs using LLDB called Ruminate, with an accompanying paper written about it, but it has to jump through some rather expensive IPC hoops in order to do so.

Is this IPC just the debugging of the other process? Or is it more than that?

> 
> After talking with Todd Fiala, he suggested writing an implementation of NativeProcessProtocol and NativeThreadProtocol that inspects the local process. This would allow same-process debugging without the expensive IPC that Ruminate has.

What is the IPC needed for? Getting the backtraces? What exactly are you looking to eliminate?

> 
> Basically I want to be able to use LLDB as a high-level API to inspect your own process, with all of the details of debug symbols, stack traversal, etc handled for you.
> 
> Thoughts?

We currently don't have the "attach and inspect only" of a process, and we currently can't debug ourselves. So the main question is do we try to build this into NativeProcessProtocol and NativeThreadProtocol, or do we make other classes for them.

Greg