4 ms·
The best way to use DTrace is by writing your own DTrace scripts rather than using dtruss or another wrapper. Also, OS X does have a command similar to 'strace
by cwzwarich 14y ago
The best way to use DTrace is by writing your own DTrace scripts rather than using dtruss or another wrapper.
Also, OS X does have a command similar to 'strace' called 'trace'. The simplest way to use it is like this:
$ sudo trace -L <filename>
<terminate with ^C>
$ trace -R <filename> /usr/share/misc/trace.codes
That will print out a formatted list of events with timestamps, etc. BSD system calls are formatted with the 'BSC_' prefix, and Mach system calls are formatted with the 'MSC_' prefix.
If you run 'trace -h' it will tell you about more options for filtering, tracing for a fixed period of time, etc.
- lallysingh 14y agodtrace's pid provider should do this as well.
- cwzwarich 14y agoThe pid provider is for probing calls and returns of userspace functions (the fbt provider serves a similar role for kernel functions). The closest things to this functionality would be the syscall and mach_trap providers. For the scheduling information that trace gives you, you could also use the DTrace sched provider. There are lots of events that trace captures that don't have any DTrace analogue, e.g. the CPU power state events. DTrace is better for setting up targeted scripts that probe a relatively small number of events, especially when the precise events you want to capture depend on dynamic conditions, or for cases where you need backtraces. If you just want a firehose to analyze later, trace is better and has lower overhead. DTrace is also handy because of the builtin aggregation, which often saves you from having to write an awk or perl script to analyze trace output.