On Tue, Jan 20, 2009 at 09:33:42AM -0800, Rob Clark wrote: > Summary comparing systemtap and dtrace > http://sourceware.org/systemtap/wiki/SystemtapDtraceComparison > > It looks like we are ahead in a few spots also.
"We" being DTrace? That comparison is wrong or misleading in a number of areas. For example: DTrace can instrument every instruction in user-land, whereas that page says SystemTap can instrument "zillions (statements, functions)" and DTrace only "millions (functions, markers)." The contention that SystemTap can access "any context-visible variable as preserved by compiler" is misleading unless it is customary to ship production object code with low optimization levels and with full debug information. The same observation applies to the ability to set probes on statements; production code does not normally ship with optimization turned off and debug information. Another misleading item: "full control structures (conditionals, loops, functions)" -- DTrace does not provide loops and functions in D _by design_, _on purpose_, _for good reason_, but no discussion is given. Yet another: "kernel coupling - interdependent development/schedule" -- methinks that the number of operating systems to which DTrace has been ported is proof that the level of such coupling is not "[a] lot." There are other such problems. Finally, I'm not sure what is meant by "binary tracing" in SystemTap. If that means "tracing arbitrary memory buffers" then that is definitely supported by DTrace. If it means "tracing arbitrary instructions" then that is true only of the DTrace pid provider (user-land). Much bandwidth has been spilled on this topic. If you want more you can find it in the mailing list archives for DTrace, and in SystemTap's, as well as in plenty of blog entries. Nico -- _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
