From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <8dc3b4a146dde183a3896542f92e9507@coraid.com> References: <55c52a87f0b8c0ac12a81a150f110b2b@brasstown.quanstro.net> <20091101184418.GM19125@gradx.cs.jhu.edu> <1257590719.28012.1344036163@webmail.messagingengine.com> <20091110003356.GW19125@gradx.cs.jhu.edu> <13426df10911091646o305d2ab2g664aa719e5b9a0e9@mail.gmail.com> <8dc3b4a146dde183a3896542f92e9507@coraid.com> Date: Mon, 9 Nov 2009 22:08:18 -0500 Message-ID: <9ab217670911091908u25e0a23bk838bd67c460492ac@mail.gmail.com> From: "Devon H. O'Dell" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] dtrace for plan 9 Topicbox-Message-UUID: 98656e06-ead5-11e9-9d60-3106f5b1d025 2009/11/9 erik quanstrom : >> > 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, perha= ps?) >> > support backwards jumps. =A0Am I mistaken in my understanding of DTrac= e? >> >> 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