I'd like to use DTrace on Ubuntu.
https://github.com/dtrace4linux/linux
There is one for Linux above, the github.
- I wonder if dtrace for linux is just same with dtrace for other OS(Solaris, FreeBSD, OSX).
- I'd like to find a tutorial for using this(dtraceforlinux).
- I wonder if the tutorial for dtrace for solaris below are right for me.
http://www.oracle.com/technetwork/server-storage/solaris/dtrace-tutorial-142317.html
Thank you in advance. Journeyer
Answer
As author of dtrace4linux, let me answer.
In essence, dtrace on Linux/MacOS/FreeBSD/Solaris is the same - we are all based on the same source code with the same goals. Because there is no central maintainer, the codes are effectively forks, with Solaris being considered the master. The major source code difference is the glue for each platform.
DTrace is a combination of a number of things:
- kernel driver
- user space "dtrace" command
- probe function mechanisms (eg syscall, fbt)
- scripting language
Look at syscall tracing its pretty straightforward:
$ dtrace -n syscall::open:
.....
This traps every open system call, no matter who executed it. If you know Unix, you know the syscall is approximately:
open(char *filename, int flags, [int perms])
So, arg0 is the string "filename". But this is where things differ. The C lib function is as above, but this maps to a system call, which is something like:
open(int someflags, char *filename, int userflags, int perms)
So the filename is not in arg0, but arg1. (Apologies if the above is wrong - I think open() is the same in the kernel and user space, but this is not true, e.g. for the stat() family of functions).
This is where some of the "portability" issues of DTrace arise - if you use a Solaris guide to dtrace, and try to run some of the scripts or examples, you might find they dont work the same. In theory, this is Linux (my) fault, and dtrace4linux should be modified to hide this.
That all applies to syscalls.
Now lets look at fbt. Fbt is just function tracing - any function - with any parameters. You can trace the linux function which implements the open() syscall (its called sys_open [possibly]). If you trap this function:
$ dtrace -n fbt::sys_open:
then you have to look at the kernel source code to see what arg0, arg1, arg2, etc is. And almost certainly is different to Solaris or MacOS - its Linux's implementation detail.
But you may want access to some argument, e.g. to get hold of some internal kernel data structure (TCP, Disk driver, USB driver, etc). Solaris provides "providers" which are higher level ways to access data structures than knowing "arg3 is a 'struct foo *'". Without these providers, scripts would be totally opsys dependent and no portability. Most people dont care what a "tcp" structure looks like, but want access to key fields like pktin, pktout, rcvbytes, sndbytes.
In summary dtrace4linux and Solaris dtrace provides a portability layer to allow access to these features or structures, but neither dtrace4linux or Solaris attempts to do a complete job to provide portability across the thousands of structures in each kernel.
In general, you can take solaris tutorial scripts and use them to try and understand what doesnt work, but attempting to use them 'as-is' will frustrate you if you do not know what to look for.
I consider dtrace4linux as "not bad" and "not good enough" to hide these differences. (dtrace4linux is about on par with MacOS - if you use the Solaris tutorials, some may not work on a Mac or FreeBSD).