[lldb-dev] Some hints for Dtrace support.
Pedro F. Giffuni
giffunip at tutopia.com
Mon May 23 12:08:04 PDT 2011
--- On Mon, 5/23/11, Greg Clayton <gclayton at apple.com> wrote:
> I think the biggest thing that is
> missing in linux and MacOSX is that we don't have a central
> place that allows multiple debug connections to a process.
> I believe Sun has the ability to have many different
> processes set breakpoints within another process (through
> libproc?), whereas both linux and darwin have the debuggers
> do all of the work in the debugger itself and they don't
> share the process with any other processes.
I haven't used linux in a long time but last I saw they
tended to abuse the procfs facility, which can bring serious
security issues. (By this comment you will notice I am a BSD
user ;) ). In this case I prefer the debugger doing
the heavy lifting.
> We can, as a debugger, effectively do all that dtrace can
> do and we can also provide a lot more:
> - function locals (not just args that were hard coded into
> a compact type format (CTF))
> - stack backtraces with full inline information
> The two programs have very different goals. dtrace is
> willing to lose information in its traces so that it can
> keep the process running as fast as possible. lldb will stop
> at breakpoint locations and is willing to take more time to
> gather complete information.
> I am not sure the two overlap significantly enough warrant
> merging in any commands, though if you have any use cases
> that show otherwise I am more than willing to keep an open
Honestly I haven't played enough with Dtrace and I don't have
a Dtrace-enabled debugger either :(.
This blog entry gives some hints, but the related slides
don't seem to be available:
> The one area I can see debuggers and dtrace interacting
> more is to have dtrace have the ability to search for a
> certain set of conditions using its fast performance, and
> get to a point where it can hand off a process over to a
> debugger when the specified criteria are met.
> Is there anything that you have wanted from dtrace within
> the debugger?
I'd be happy if the debugger just knows about CTF.
Like most end users I only care about debuggers when I get
a coredump, and I am unlikely to have symbol information
(most packages and their dependencies come stripped) so
anything I can get from the coredump is valuable and
Dtrace tends to know what is happening in the kernel.
This is all wishful thinking though, for now my priority
will be to get lldb *building* in my fav. platform ;).
More information about the lldb-dev