Re: [9fans] dtrace for plan 9

["Devon H. O'Dell" <devon.odell@gmail.com>]

2009/11/9 erik quanstrom <quanstro@coraid.com>:
>> > I keep hearing this brought up, but (while I am not an expert) AFAICT, the
>> > runtime for each D hook should be strictly bounded by the number of
>> > instructions lobbed in, since D does not (without root override, perhaps?)
>> > support backwards jumps.  Am I mistaken in my understanding of DTrace?
>>
>> You are right. I don't think runtime is unbounded. At the same time,
>> I'm still trying to locate example scripts to get an idea of how
>> complex it is. I'm talking to people at sun to get a handle on the
>> question.

D doesn't do loops or conditionals. You can't branch. But you can get
around that with some tricks, like aggregations and predicates. For
what you'd typically use it for, it should be ok. That said, my
knowledge of DTrace internals greatly surpasses my knowledge of how to
actually use it, so I'll let Roman help out on that front :)

> before we go all crazy, has anyone else tried ron's
> great tracing?

It's good, I read the paper and played around with it while I was
doing some 9vx work. But it's not really the same. Devtrace implements
a subset of DTrace's functionality.

DTrace does more than syscalls, and a lot of the talk on this thread
seems to be focused around that, so please let me clarify a bit. This
is partially due to compiling binaries with CTF (Compact C Type Format
-- when I asked the guys about this, they laughed and said it was so
compact that they cut off a C from the acronym). CTF stores type /
name / size information about symbols in a program, but is not as
heavy as DWARF: no line information is stored, no file references,
etc. The data is stored in an extended ELF header, compressed with
zlib.

DTrace by itself is pretty lame. It needs providers to be interesting.
By itself, it's a very limited interpreter that supports BEGIN and
END, and a couple other tiny things (ERROR, maybe?). Devtrace would be
analogous to the syscall provider for DTrace, from my understanding.

Because of CTF, DTrace also has providers to do function boundary
tracing (function entries / exits) on any executable (including a live
kernel) that has been compiled with CTF symbols. The fasttrap (or PID)
provider allows for instruction level tracing by inserting a
breakpoint at a given location, catching it, executing what was
previously at the breakpoint, executing the relevant D code (which may
in turn be traced by DTrace up to a finite amount of recursion), until
it comes back up the stack. The USDT providers allow userland
applications -- languages such as Perl, PHP, or Python for instance --
to register DTrace hooks. Once a userland app has done this, you can
follow e.g. a Python function call from the script, through Python,
through libc, through a syscall, all the way to a device driver... and
back up again.

It's also fairly easy to do this. I was at a party with the Sun guys
at OSCon in 2005. Wez Furlong wrote a DTrace provider for PHP in about
30 minutes with Bryan Cantrill, who then rather excitedly ran to me
explaining how I needed to come look (this is a gross understatement
for brevity). It was pretty cool, and the code needed for the DTrace
hooking was smaller than the PHP module skeleton code.

While extending it may be done relatively easy, it is quite big. When
I was working on porting it to FreeBSD (before jb@ essentially usurped
the project, anyway), I spent 3 weeks getting CTF and the base DTrace
provider ported over. Granted, I was much less experienced than now,
but it is a significant amount of work to reproduce all the
functionality. I'd estimate a finished version to be about the size of
the Plan 9 kernel.

--me