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