forked from dtrace4linux/linux
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Status.txt
105 lines (88 loc) · 4.84 KB
/
Status.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
A dtrace spectator asked me for a "status" of dtrace (Edward Peschko) -
a very good suggestion, so that people dont have to figure out from my
titbits in the blog (http://www.crtags.blogspot.com), what works and what
doesnt work.
Working Features
o Works on AS4/64 bit kernels, Ubuntu 8.xx - 12.xx (32-bit and 64-bit).
Not every kernel version tested, but should build on at least 2.6.12
onwards.
o Tested up to 3.4 kernels, but not proven/tested under later kernels.
o FBT Provider: fully functional, except argument types are not presently
supported. You can access arg0, arg1, ... as values or pointers but
no type info to support structure accessing. Should be safe to probe
all functions in the kernel. (DTrace keeps a toxic list of functions
we mustnt touch)
o INSTR Provider: example provider for instruction level tracing - works
on 32/64 bit kernels.
o SYSCALL provider: fully implemented - can trace all syscalls. We set
the "module" to "x32" or "x64" so that you can independently trace
32bit syscalls on a 64bit kernel.
o SDT Provider: first provider io:::start/io:::done "works" but debugging
the typed arguments (args[0], args[1], args[2])
o dtrace.conf permissioning model to avoid need for root access
o stack()/ustack(): implemented, but at the mercy of code which doesnt
have frame pointers (in kernel or user space - stacks may have bogus
entries).
o Kernel GPF protection: all D scripts and pointer accesses are protected
from panicing the kernel.
o D scripts should work, except where they rely on providers/features
not yet ready in Linux/dtrace (eg cannot run standard scripts like
iosnoop.d or other scripts out there).
o vminfo provider - probes for the stats in /proc/vmstats
o PID provider (dtrace -n pidNNN:::).
Partially Working / Not yet quality controlled:
o ARM Support - as of this writing, compiles, but not fully debugged.
Not tested on a variety of ARM CPUs and configurations. Tested on
debian-armel VM.
o USDT Basic C/C++ works - demo program supplied, but not fully
quality controlled that all D functions work.
o CTF framework for the kernel: Since we dont build the kernel, the
kernel lacks the .SUNW_ctf symbol table needed by dtrace to allow
D scripts to use struct/union pointers to view data structures.
This is currently work in progress to provide an alternate mechanism.
Not really working / not yet implemented
o Java, Python, Ruby, etc: No attempt to test the other languages in
a USDT context. For non-java, it should be possible to build
instrumented apps (drti.o is provided to link with). I havent
reviewed what the jstack() code does not tested to see if it
works/not-works. Shouldnt be an issue technically in getting this
to work assuming the process control issues in the PID provider are
resolved.
o Most of the SDT probes (NFS, VM, etc) are not yet implemented.
Will require special work because we do not modify kernel source and
kernel build is not in our control.
Other:
o Use on Xen/paravirtualised kernels (Dom-0 or PVM guest) may
hang on IPI cross-calls.
FAQ
Q Can this be used in a production context?
A Dont know. I believe so but please do not take my word for it. If your
kernel is a recent release (2.6.28+) then it should work out of the box
I advise people to thorough test and try out DTrace before applying
to a machine, in case it crashes the target system. Crashes may be
caused due to the compilation choosing wrong defaults for your kernel,
or coding/bad-practise bugs in this version of DTrace.
Q Why are you doing this?
A Because its relaxing and a challenge and I want dtrace to be available
everywhere so that when I want it, I know its there. If distros could
bundle it - superb. If I have to build it myself, less so.
Q What can I do ?
A You can use it, report issues, track progress, submit patches or suggestions
Q What about Oracle, the CDDL license, GPL?
A What about them? Nobody has told me this is breaking any license, and I
have no qualms with Oracle.
Q What about systemtap?
A Super! Competition. dtrace can be used around systemtap - trace systemtap
executing. I dont know much about systemtap, and it may do more clever
things than dtrace. In which case Dtrace/linux will evolve to try and
be a better systemtap than systemtap
Q Is this real?
A Yes
Q Doesnt Oracle provide DTrace for UEL?
A Yes. Oracle started work in 2011, and provide a version of DTrace which
is intimate with their kernel version. As of mid-2012, the Oracle
version isnt as functionally complete compared to this version, and
their version isnt available for non-Oracle kernels. They may have the
advantage of integrating SDT probes into the kernel source, and its
definitely worth researching their release to see if it is more applicable,
or higher quality, or more features.