<div>On Fri Jul 11 2014 at 11:17:55 AM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div>My implementation of NativeProcessProtocol does nothing when you try to attach to a process.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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.<br></blockquote><div><br></div><div>
I hadn't looked at lldb_private::Host. I'll have a look at it and get back to you. NativeProcessProtocol seems like the right layer to add this kind of change to though, as that allows lldb to conceptually continue debugging a remote process, that remote process just happens to be itself.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
More comments below.<br>
<br>
> On Jul 10, 2014, at 11:40 AM, Russell Harmon <<a href="mailto:eatnumber1@google.com" target="_blank">eatnumber1@google.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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.<br>

<br>
Is this IPC just the debugging of the other process? Or is it more than that?<br></blockquote><div><br></div><div>It's more than that. When you initialize Ruminate in your own process, it fork()s a process which initializes and controls lldb. The debugger process also starts an RPC server exporting an API to control LLDB. The debugee (or parent process) connects to this RPC server, thereby allowing it to debug itself, proxied via the child process. The startup is actually a bit more expensive than this, but this is the general workflow.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> 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.<br>

<br>
What is the IPC needed for? Getting the backtraces? What exactly are you looking to eliminate?<br></blockquote><div><br></div><div>Well, for the ptrace() IPC, I have lldb stop the debugee for getting array members, function argument types, enum members and enumerating the members of an sbtype (struct members). See <a href="https://github.com/eatnumber1/ruminate/blob/08d11440d75e42626bcc06b2c090c97ff2676be3/python/type_impl.py#L123">getMembers</a> in Ruminate. It's been awhile since I wrote that code, but if I remember correctly, the LLDB's API didn't allow me to perform these operations without stopping the debugee.</div>
<div><br></div><div>For the RPCs, well all of the information about the debugee is in the debugger process, so even operations that don't require stopping the debugee involve an RPC.</div><div><br></div><div>I'd also like to be able to get rid of <a href="https://github.com/eatnumber1/ruminate/blob/08d11440d75e42626bcc06b2c090c97ff2676be3/python/debugger_impl.py#L123">this</a> which is disgusting and should die in a fire, but is necessary currently to get information about an array for which you have no value (aka, can't go through SBValue).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> 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.<br>
><br>
> Thoughts?<br>
<br>
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.<br>
</blockquote><div><br></div><div>It seemed to make sense to me to implement NativeProcessProtocol (why detailed already above), but if you think there's a better way, I'm all ears.</div><div><br></div><div>As for "attach and inspect only", I wasn't really treating that as a separate feature. I manipulate lldb to work like that by changing the signal disposition to pass all signals through (hence my previous patch to add support for changing the signal disposition). Granted, I have to stop the debugee in some places, but my efforts were going to move towards making those stops unnecessary once I had a working local Native*Protocol implementation.</div>
<div><br></div><div>Re: Todd's response which arrived while I was writing this email:</div><div><br></div><div>I think ideally you'd be able to use most of the SB API on your own process, potentially even stopping and setting breakpoints on other threads. Also, you'd be able to do the ruminate-necessary operations of enumerating the type system - enumerating fields of structs, arguments, functions, etc. Does that make sense? I hope I'm getting my thoughts across clearly.</div>