1.\" Copyright (c) 2013-2015 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 72The 73.Nm 74macros allow programmers to define static trace points in kernel code. 75These trace points are used by the 76.Nm 77framework to create DTrace probes, allowing the code to be instrumented 78using 79.Xr dtrace 1 . 80By default, 81.Nm 82trace points are disabled and have no effect on the surrounding code. 83When a DTrace probe corresponding to a given trace point is enabled, threads 84that execute the trace point will call a handler and cause the probe to fire. 85Moreover, trace points can take arguments, making it possible to pass data 86to the DTrace framework when an enabled probe fires. 87.Pp 88Multiple trace points may correspond to a single DTrace probe, allowing 89programmers to create DTrace probes that correspond to logical system events 90rather than tying probes to specific code execution paths. 91For instance, a DTrace probe corresponding to the arrival of an IP packet into 92the network stack may be defined using two 93.Nm 94trace points: one for IPv4 packets and one for IPv6 packets. 95.Pp 96In addition to defining DTrace probes, the 97.Nm 98macros allow programmers to define new DTrace providers, making it possible to 99namespace logically-related probes. 100An example is FreeBSD's sctp provider, which contains 101.Nm 102probes for FreeBSD's 103.Xr sctp 4 104implementation. 105.Pp 106The 107.Fn SDT_PROVIDER_DECLARE 108and 109.Fn SDT_PROVIDER_DEFINE 110macros are used respectively to declare and define a DTrace provider named 111.Ar prov 112with the 113.Nm 114framework. 115A provider need only be defined once; however, the provider must be declared 116before defining any 117.Nm 118probes belonging to that provider. 119.Pp 120Similarly, the 121.Fn SDT_PROBE_DECLARE 122and 123.Fn SDT_PROBE_DEFINE* 124macros are used to declare and define DTrace probes using the 125.Nm 126framework. 127Once a probe has been defined, trace points for that probe may be added to 128kernel code. 129DTrace probe identifiers consist of a provider, module, function and name, all 130of which may be specified in the 131.Nm 132probe definition. 133Note that probes should not specify a module name: the module name of a probe is 134used to determine whether or not it should be destroyed when a kernel module is 135unloaded. 136See the 137.Sx BUGS 138section. 139Note in particular that probes must not be defined across multiple kernel 140modules. 141.Pp 142If 143.Ql - 144character (dash) is wanted in a probe name, 145then it should be represented as 146.Ql __ 147(double underscore) in the probe 148.Ar name 149parameter passed to various 150.Fn SDT_* 151macros, 152because of technical reasons 153(a dash is not valid in C identifiers). 154.Pp 155The 156.Fn SDT_PROBE_DEFINE* 157macros also allow programmers to declare the types of the arguments that are 158passed to probes. 159This is optional; if the argument types are omitted (through use of the 160.Fn SDT_PROBE_DEFINE 161macro), users wishing to make use of the arguments will have to manually cast 162them to the correct types in their D scripts. 163It is strongly recommended that probe definitions include a declaration of their 164argument types. 165.Pp 166The 167.Fn SDT_PROBE_DEFINE*_XLATE 168macros are used for probes whose argument types are to be dynamically translated 169to the types specified by the corresponding 170.Ar xarg 171arguments. 172This is mainly useful when porting probe definitions from other operating 173systems. 174As seen by 175.Xr dtrace 1 , 176the arguments of a probe defined using these macros will have types which match 177the 178.Ar xarg 179types in the probe definition. 180However, the arguments passed in at the trace point will have types matching the 181native argument types in the probe definition, and thus the native type is 182dynamically translated to the translated type. 183So long as an appropriate translator is defined in 184.Pa /usr/lib/dtrace , 185scripts making use of the probe need not concern themselves with the underlying 186type of a given 187.Nm 188probe argument. 189.Pp 190The 191.Fn SDT_PROBE* 192macros are used to create 193.Nm 194trace points. 195They are meant to be added to executable code and can be used to instrument the 196code in which they are called. 197.Sh PROVIDERS 198A number of kernel DTrace providers are available. 199In general, these providers define stable interfaces and should be treated as 200such: existing D scripts may be broken if a probe is renamed or its arguments 201are modified. 202However, it is often useful to define ad-hoc 203.Nm 204probes for debugging a subsystem or driver. 205Similarly, a developer may wish to provide a group of 206.Nm 207probes without committing to their future stability. 208Such probes should be added to the 209.Ql sdt 210provider instead of defining a new provider. 211.Sh EXAMPLES 212The DTrace providers available on the current system can be listed with 213.Bd -literal -offset indent 214dtrace -l | sed 1d | awk '{print $2}' | sort -u 215.Ed 216.Pp 217A detailed list of the probes offered by a given provider can be obtained by 218specifying the provider using the 219.Fl P 220flag. 221For example, to view the probes and argument types for the 222.Ql sched 223provider, run 224.Bd -literal -offset indent 225dtrace -lv -P sched 226.Ed 227.Pp 228The following probe definition will create a DTrace probe called 229.Ql icmp:::receive-unreachable , 230which would hypothetically be triggered when the kernel receives an ICMP packet 231of type Destination Unreachable: 232.Bd -literal -offset indent 233SDT_PROVIDER_DECLARE(icmp); 234 235SDT_PROBE_DEFINE1(icmp, , , receive__unreachable, 236 "struct icmp *"); 237 238.Ed 239This particular probe would take a single argument: a pointer to the struct 240containing the ICMP header for the packet. 241Note that the module name of this probe is not specified. 242.Pp 243Consider a DTrace probe which fires when the network stack receives an IP 244packet. 245Such a probe would be defined by multiple tracepoints: 246.Bd -literal -offset indent 247SDT_PROBE_DEFINE3(ip, , , receive, "struct ifnet *", 248 "struct ip *", "struct ip6_hdr *"); 249 250int 251ip_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 260int 261ip6_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 271In particular, the probe should fire when the kernel receives either an IPv4 272packet or an IPv6 packet. 273.Pp 274Consider the ICMP probe discussed above. 275We note that its second argument is of type 276.Ar struct icmp , 277which is a type defined in the FreeBSD kernel to represent the ICMP header of 278an ICMP packet, defined in RFC 792. 279Linux has a corresponding type, 280.Ar struct icmphdr , 281for the same purpose, but its field names differ from FreeBSD's 282.Ar struct icmp . 283Similarly, illumos defines the 284.Ar icmph_t 285type, again with different field names. 286Even with the 287.Ql icmp:::pkt-receive 288probes defined in all three operating systems, 289one would still have to write OS-specific scripts to extract a given field out 290of the ICMP header argument. 291Dynamically-translated types solve this problem: one can define an 292OS-independent 293.Xr c 7 294struct to represent an ICMP header, say 295.Ar struct icmp_hdr_dt , 296and define translators from each of the three OS-specific types to 297.Ar struct icmp_hdr_dt , 298all in the 299.Xr dtrace 1 300library path. 301Then the FreeBSD probe above can be defined with: 302.Bd -literal -offset indent 303SDT_PROBE_DEFINE1_XLATE(ip, , , receive, "struct icmp *", 304 "struct icmp_hdr_dt *"); 305.Ed 306.Sh SEE ALSO 307.Xr dtrace 1 , 308.Xr dtrace_io 4 , 309.Xr dtrace_ip 4 , 310.Xr dtrace_proc 4 , 311.Xr dtrace_sched 4 , 312.Xr dtrace_tcp 4 , 313.Xr dtrace_udp 4 314.Sh AUTHORS 315.An -nosplit 316DTrace and the 317.Nm 318framework were originally ported to FreeBSD from Solaris by 319.An John Birrell Aq Mt jb@FreeBSD.org . 320This manual page was written by 321.An Mark Johnston Aq Mt markj@FreeBSD.org . 322.Sh BUGS 323The 324.Nm 325macros allow the module and function names of a probe to be specified as part of 326a probe definition. 327The DTrace framework uses the module name of probes to determine which probes 328should be destroyed when a kernel module is unloaded, so the module 329name of a probe should match the name of the module in which its defined. 330.Nm 331will set the module name properly if it is left unspecified in the probe 332definition; see the 333.Sx EXAMPLES 334section. 335.Pp 336One of the goals of the original 337.Nm 338implementation (and by extension, of FreeBSD's port) is that inactive 339.Nm 340probes should have no performance impact. 341This is unfortunately not the case; 342.Nm 343trace points will add a small but non-zero amount of latency to the code 344in which they are defined. 345A more sophisticated implementation of the probes will help alleviate this 346problem. 347