[lldb-dev] Same-Process Debugging

Todd Fiala tfiala at google.com
Mon Jul 14 09:12:07 PDT 2014


Hey Russell,

It might be worth having you sketch out what would be an ideal way for you
to make use of the functionality of LLDB (i.e. without the expensive IPC).
 We might then be able to brainstorm how you can achieve your goals from
what we have now, which might have nothing to do with the Native* classes.

-Todd


On Fri, Jul 11, 2014 at 11:17 AM, Greg Clayton <gclayton at apple.com> wrote:

> 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
>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>



-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140714/a98d0946/attachment.html>


More information about the lldb-dev mailing list