]> CyberLeo.Net >> Repos - FreeBSD/releng/10.2.git/blob - share/man/man9/SDT.9
- Copy stable/10@285827 to releng/10.2 in preparation for 10.2-RC1
[FreeBSD/releng/10.2.git] / share / man / man9 / SDT.9
1 .\" Copyright (c) 2013 Mark Johnston <markj@freebsd.org>
2 .\" All rights reserved.
3 .\"
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
6 .\" are met:
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\"    notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\"    notice, this list of conditions and the following disclaimer in the
11 .\"    documentation and/or other materials provided with the distribution.
12 .\"
13 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
14 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
15 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
16 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
17 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
18 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
19 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
20 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
21 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
22 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
23 .\" SUCH DAMAGE.
24 .\"
25 .\" $FreeBSD$
26 .\"
27 .Dd April 18, 2015
28 .Dt SDT 9
29 .Os
30 .Sh NAME
31 .Nm SDT
32 .Nd a DTrace framework for adding statically-defined tracing probes
33 .Sh SYNOPSIS
34 .In sys/param.h
35 .In sys/queue.h
36 .In sys/sdt.h
37 .Fn SDT_PROVIDER_DECLARE prov
38 .Fn SDT_PROVIDER_DEFINE prov
39 .Fn SDT_PROBE_DECLARE prov mod func name
40 .Fn SDT_PROBE_DEFINE prov mod func name
41 .Fn SDT_PROBE_DEFINE0 prov mod func name
42 .Fn SDT_PROBE_DEFINE1 prov mod func name arg0
43 .Fn SDT_PROBE_DEFINE2 prov mod func name arg0 arg1
44 .Fn SDT_PROBE_DEFINE3 prov mod func name arg0 arg1 arg2
45 .Fn SDT_PROBE_DEFINE4 prov mod func name arg0 arg1 arg2 arg3
46 .Fn SDT_PROBE_DEFINE5 prov mod func name arg0 arg1 arg2 arg3 arg4
47 .Fn SDT_PROBE_DEFINE6 prov mod func name arg0 arg1 arg2 arg3 arg4 arg5
48 .Fn SDT_PROBE_DEFINE7 prov mod func name arg0 arg1 arg2 arg3 arg4 arg5   \
49     arg6
50 .Fn SDT_PROBE_DEFINE0_XLATE prov mod func name
51 .Fn SDT_PROBE_DEFINE1_XLATE prov mod func name arg0 xarg0
52 .Fn SDT_PROBE_DEFINE2_XLATE prov mod func name arg0 xarg0 arg1 xarg1
53 .Fn SDT_PROBE_DEFINE3_XLATE prov mod func name arg0 xarg0 arg1 xarg1 \
54     arg2 xarg2
55 .Fn SDT_PROBE_DEFINE4_XLATE prov mod func name arg0 xarg0 arg1 xarg1 \
56     arg2 xarg2 arg3 xarg3
57 .Fn SDT_PROBE_DEFINE5_XLATE prov mod func name arg0 xarg0 arg1 xarg1 \
58     arg2 xarg2 arg3 xarg3 arg4 xarg4
59 .Fn SDT_PROBE_DEFINE6_XLATE prov mod func name arg0 xarg0 arg1 xarg1 \
60     arg2 xarg2 arg3 xarg3 arg4 xarg4 arg5 xarg5
61 .Fn SDT_PROBE_DEFINE7_XLATE prov mod func name arg0 xarg0 arg1 xarg1 \
62     arg2 xarg2 arg3 xarg3 arg4 xarg4 arg5 xarg5 arg6 xarg6
63 .Fn SDT_PROBE0 prov mod func name
64 .Fn SDT_PROBE1 prov mod func name arg0
65 .Fn SDT_PROBE2 prov mod func name arg0 arg1
66 .Fn SDT_PROBE3 prov mod func name arg0 arg1 arg2
67 .Fn SDT_PROBE4 prov mod func name arg0 arg1 arg2 arg3
68 .Fn SDT_PROBE5 prov mod func name arg0 arg1 arg2 arg3 arg4
69 .Fn SDT_PROBE6 prov mod func name arg0 arg1 arg2 arg3 arg4 arg5
70 .Fn SDT_PROBE7 prov mod func name arg0 arg1 arg2 arg3 arg4 arg5 arg6
71 .Sh DESCRIPTION
72 The
73 .Nm
74 macros allow programmers to define static trace points in kernel code.
75 These trace points are used by the
76 .Nm
77 framework to create DTrace probes, allowing the code to be instrumented
78 using
79 .Xr dtrace 1 .
80 By default,
81 .Nm
82 trace points are disabled and have no effect on the surrounding code.
83 When a DTrace probe corresponding to a given trace point is enabled, threads
84 that execute the trace point will call a handler and cause the probe to fire.
85 Moreover, trace points can take arguments, making it possible to pass data
86 to the DTrace framework when an enabled probe fires.
87 .Pp
88 Multiple trace points may correspond to a single DTrace probe, allowing
89 programmers to create DTrace probes that correspond to logical system events
90 rather than tying probes to specific code execution paths.
91 For instance, a DTrace probe corresponding to the arrival of an IP packet into
92 the network stack may be defined using two
93 .Nm
94 trace points: one for IPv4 packets and one for IPv6 packets.
95 .Pp
96 In addition to defining DTrace probes, the
97 .Nm
98 macros allow programmers to define new DTrace providers, making it possible to
99 namespace logically-related probes.
100 An example is FreeBSD's sctp provider, which contains
101 .Nm
102 probes for FreeBSD's
103 .Xr sctp 4
104 implementation.
105 .Pp
106 The
107 .Fn SDT_PROVIDER_DECLARE
108 and
109 .Fn SDT_PROVIDER_DEFINE
110 macros are used respectively to declare and define a DTrace provider named
111 .Ar prov
112 with the
113 .Nm
114 framework.
115 A provider need only be defined once; however, the provider must be declared
116 before defining any
117 .Nm
118 probes belonging to that provider.
119 .Pp
120 Similarly, the
121 .Fn SDT_PROBE_DECLARE
122 and
123 .Fn SDT_PROBE_DEFINE*
124 macros are used to declare and define DTrace probes using the
125 .Nm
126 framework.
127 Once a probe has been defined, trace points for that probe may be added to
128 kernel code.
129 DTrace probe identifiers consist of a provider, module, function and name, all
130 of which may be specified in the
131 .Nm
132 probe definition.
133 Note that probes should not specify a module name: the module name of a probe is
134 used to determine whether or not it should be destroyed when a kernel module is
135 unloaded.
136 See the
137 .Sx BUGS
138 section.
139 Note in particular that probes must not be defined across multiple kernel
140 modules.
141 .Pp
142 If
143 .Ql -
144 character (dash) is wanted in a probe name,
145 then it should be represented as
146 .Ql __
147 (double underscore) in the probe
148 .Ar name
149 parameter passed to various
150 .Fn SDT_*
151 macros,
152 because of technical reasons
153 (a dash is not valid in C identifiers).
154 .Pp
155 The
156 .Fn SDT_PROBE_DEFINE*
157 macros also allow programmers to declare the types of the arguments that are
158 passed to probes.
159 This is optional; if the argument types are omitted (through use of the
160 .Fn SDT_PROBE_DEFINE
161 macro), users wishing to make use of the arguments will have to manually cast
162 them to the correct types in their D scripts.
163 It is strongly recommended that probe definitions include a declaration of their
164 argument types.
165 .Pp
166 The
167 .Fn SDT_PROBE_DEFINE*_XLATE
168 macros are used for probes whose argument types are to be dynamically translated
169 to the types specified by the corresponding
170 .Ar xarg
171 arguments.
172 This is mainly useful when porting probe definitions from other operating
173 systems.
174 As seen by
175 .Xr dtrace 1 ,
176 the arguments of a probe defined using these macros will have types which match
177 the
178 .Ar xarg
179 types in the probe definition.
180 However, the arguments passed in at the trace point will have types matching the
181 native argument types in the probe definition, and thus the native type is
182 dynamically translated to the translated type.
183 So long as an appropriate translator is defined in
184 .Pa /usr/lib/dtrace ,
185 scripts making use of the probe need not concern themselves with the underlying
186 type of a given
187 .Nm
188 probe argument.
189 .Pp
190 The
191 .Fn SDT_PROBE*
192 macros are used to create
193 .Nm
194 trace points.
195 They are meant to be added to executable code and can be used to instrument the
196 code in which they are called.
197 .Sh PROVIDERS
198 A number of kernel DTrace providers are available.
199 In general, these providers define stable interfaces and should be treated as
200 such: existing D scripts may be broken if a probe is renamed or its arguments
201 are modified.
202 However, it is often useful to define ad-hoc
203 .Nm
204 probes for debugging a subsystem or driver.
205 Similarly, a developer may wish to provide a group of
206 .Nm
207 probes without committing to their future stability.
208 Such probes should be added to the
209 .Ql sdt
210 provider instead of defining a new provider.
211 .Sh EXAMPLES
212 The DTrace providers available on the current system can be listed with
213 .Bd -literal -offset indent
214 dtrace -l | sed 1d | awk '{print $2}' | sort -u
215 .Ed
216 .Pp
217 A detailed list of the probes offered by a given provider can be obtained by
218 specifying the provider using the
219 .Fl P
220 flag.
221 For example, to view the probes and argument types for the
222 .Ql sched
223 provider, run
224 .Bd -literal -offset indent
225 dtrace -lv -P sched
226 .Ed
227 .Pp
228 The following probe definition will create a DTrace probe called
229 .Ql icmp:::receive-unreachable ,
230 which would hypothetically be triggered when the kernel receives an ICMP packet
231 of type Destination Unreachable:
232 .Bd -literal -offset indent
233 SDT_PROVIDER_DECLARE(icmp);
234
235 SDT_PROBE_DEFINE1(icmp, , , receive__unreachable,
236     "struct icmp *");
237
238 .Ed
239 This particular probe would take a single argument: a pointer to the struct
240 containing the ICMP header for the packet.
241 Note that the module name of this probe is not specified.
242 .Pp
243 Consider a DTrace probe which fires when the network stack receives an IP
244 packet.
245 Such a probe would be defined by multiple tracepoints:
246 .Bd -literal -offset indent
247 SDT_PROBE_DEFINE3(ip, , , receive, "struct ifnet *",
248     "struct ip *", "struct ip6_hdr *");
249
250 int
251 ip_input(struct mbuf *m)
252 {
253         struct ip *ip;
254         ...
255         ip = mtod(m, struct ip *);
256         SDT_PROBE3(ip, , , receive, m->m_pkthdr.rcvif, ip, NULL);
257         ...
258 }
259
260 int
261 ip6_input(struct mbuf *m)
262 {
263         struct ip6_hdr *ip6;
264         ...
265         ip6 = mtod(m, struct ip6_hdr *);
266         SDT_PROBE3(ip, , , receive, m->m_pkthdr.rcvif, NULL, ip6);
267         ...
268 }
269
270 .Ed
271 In particular, the probe should fire when the kernel receives either an IPv4
272 packet or an IPv6 packet.
273 .Pp
274 Consider the ICMP probe discussed above.
275 We note that its second argument is of type
276 .Ar struct icmp ,
277 which is a type defined in the FreeBSD kernel to represent the ICMP header of
278 an ICMP packet, defined in RFC 792.
279 Linux has a corresponding type,
280 .Ar struct icmphdr ,
281 for the same purpose, but its field names differ from FreeBSD's
282 .Ar struct icmp .
283 Similarly, illumos defines the
284 .Ar icmph_t
285 type, again with different field names.
286 Even with the
287 .Ql icmp:::pkt-receive
288 probes defined in all three operating systems,
289 one would still have to write OS-specific scripts to extract a given field out
290 of the ICMP header argument.
291 Dynamically-translated types solve this problem: one can define an
292 OS-independent
293 .Xr c 7
294 struct to represent an ICMP header, say
295 .Ar struct icmp_hdr_dt ,
296 and define translators from each of the three OS-specific types to
297 .Ar struct icmp_hdr_dt ,
298 all in the
299 .Xr dtrace 1
300 library path.
301 Then the FreeBSD probe above can be defined with:
302 .Bd -literal -offset indent
303 SDT_PROBE_DEFINE1_XLATE(ip, , , receive, "struct icmp *",
304     "struct icmp_hdr_dt *");
305 .Ed
306 .Sh SEE ALSO
307 .Xr dtrace 1
308 .Sh AUTHORS
309 .An -nosplit
310 DTrace and the
311 .Nm
312 framework were originally ported to FreeBSD from Solaris by
313 .An John Birrell Aq jb@FreeBSD.org .
314 This manual page was written by
315 .An Mark Johnston Aq markj@FreeBSD.org .
316 .Sh BUGS
317 The
318 .Nm
319 macros allow the module and function names of a probe to be specified as part of
320 a probe definition.
321 The DTrace framework uses the module name of probes to determine which probes
322 should be destroyed when a kernel module is unloaded, so the module
323 name of a probe should match the name of the module in which its defined.
324 .Nm
325 will set the module name properly if it is left unspecified in the probe
326 definition; see the
327 .Sx EXAMPLES
328 section.
329 .Pp
330 One of the goals of the original
331 .Nm
332 implementation (and by extension, of FreeBSD's port) is that inactive
333 .Nm
334 probes should have no performance impact.
335 This is unfortunately not the case;
336 .Nm
337 trace points will add a small but non-zero amount of latency to the code
338 in which they are defined.
339 A more sophisticated implementation of the probes will help alleviate this
340 problem.