-
Notifications
You must be signed in to change notification settings - Fork 226
/
Status.txt
128 lines (105 loc) · 5.66 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
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
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.
20160818 PDF
o Verified it works on Ubuntu 16.04 - 4.4 kernel.
20150306 PDF
o Took out broken "break" which caused xcall to randomly not work,
and hence drop probe collection.
20150303 PDF
o Fixes for 3.16 kernels and a rework of systrace code to support
new kernel conventions.
o The x_call.c/XCALL_NEW mode is in effect; XCALL_ORIG works better
but can crash/hang your kernel. XCALL_NEW will not deliver all
probes - easily verified with running one of the s/ scripts (eg
s/execve) - whether you get notification may depend which cpu the
target process runs on. This is not nice at all, and subject
of my next investigations why buffer flushing in the kernel is
not working.
Working Features
o Works on AS4/64 bit kernels, Ubuntu 8.xx - 16.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.16 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:::).
o ARMv6/RaspberryPi on 3.4.6 kernel (USDT is not tested or likely to work)
- the instr provider isnt supported (yet)
- no SMP support
o driver-2/hworld.c - example SDT loadable driver, demonstrating dynamic
SDT probes. See doc/sdt-probes.txt for more details.
Partially Working / Not yet quality controlled:
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.