Some hints for Dtrace support.

Hi;

I understand Dtrace is supported on MacOS X and the BSDs,
and I have seen there are patches for linux too, so I
am starting to play with it.

Solaris' MDB seems to be the only debugger that supports
Dtrace proper through a set of dcmds. It would be nice
to have similar support on lldb so, JFYI, I asked one
of Dtrace designers about it:

...

> Is there something that the debugger know about
> Dtrace? There is some ongoing work in pathDB and
> lldb as possible replacements to gdb and having
> Dtrace well supported could be really nice.

The knowledge that the debugger has of DTrace is really
limited to its ability to process in-kernel DTrace
buffers. See:

http://wikis.sun.com/display/DTrace/Postmortem+Tracing

FWIW, the mdb sources are here:

http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/mdb/

Just thought someone may want to explore it.

cheers,

Pedro.

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.

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 mind.

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?

Greg Clayton

...

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 :wink: ). 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
mind.

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:
http://blogs.oracle.com/jonh/entry/dtrace_and_mdb_1

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 ;).

cheers,

Pedro.