Searching around the Internet I ran across the purported Dtrace counterpart, SystemTap http://sourceware.org/systemtap/ or http://sourceware.org/systemtap/wiki . Current project members include Red Hat, IBM, Intel, Hitachi, and Oracle. Their Wiki has a comparison page (we could add a few features): Summary comparing systemtap and dtrace http://sourceware.org/systemtap/wiki/SystemtapDtraceComparison It looks like we are ahead in a few spots also. Rob -- This message posted from opensolaris.org
Rob Clark wrote:> Searching around the Internet I ran across the purported Dtrace counterpart, SystemTap http://sourceware.org/systemtap/ > or http://sourceware.org/systemtap/wiki . Current project members include Red Hat, IBM, Intel, Hitachi, and Oracle. > > Their Wiki has a comparison page (we could add a few features): > > Summary comparing systemtap and dtrace > http://sourceware.org/systemtap/wiki/SystemtapDtraceComparison > > It looks like we are ahead in a few spots also. > > Robhttp://blogs.sun.com/ahl/entry/dtrace_knockoffs one of many, but you have to love the whiteboard snap
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 --
The only think you need to know about that comparison and about that project is contained in the first line of the wiki: systemtap DTrace license GPL CDDL The entries below that line are mere minutiae as far as their developers are concerned. On the other hand, Paul Fox has been quietly working on his port of DTrace to Linux. I''m excited to see how the final version will be received. Adam On Tue, Jan 20, 2009 at 09:33:42AM -0800, Rob Clark wrote:> Searching around the Internet I ran across the purported Dtrace counterpart, SystemTap http://sourceware.org/systemtap/ > or http://sourceware.org/systemtap/wiki . Current project members include Red Hat, IBM, Intel, Hitachi, and Oracle. > > Their Wiki has a comparison page (we could add a few features): > > Summary comparing systemtap and dtrace > http://sourceware.org/systemtap/wiki/SystemtapDtraceComparison > > It looks like we are ahead in a few spots also. > > Rob > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
> 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?Yes.> 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)." > ...It''s a Wiki, please fix it.> ... > 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."If they have a feature that we do not then let us add it and be way ahead. Rob -- This message posted from opensolaris.org
> > Rob Clark wrote: > > Searching around the Internet I ran across the purported Dtrace counterpart, SystemTap > > http://sourceware.org/systemtap/ or http://sourceware.org/systemtap/wiki . ....> dmick wrote: > http://blogs.sun.com/ahl/entry/dtrace_knockoffs > one of many, but you have to love the whiteboard snap+1 - Good link. -- This message posted from opensolaris.org
Adam Leventhal <ahl at eng.sun.com> wrote:> The only think you need to know about that comparison and about that project > is contained in the first line of the wiki: > > systemtap DTrace > license GPL CDDL;-) I was also interested on what table entries would really make sense as the list does not look like a real comparison.> The entries below that line are mere minutiae as far as their developers are > concerned. On the other hand, Paul Fox has been quietly working on his port > of DTrace to Linux. I''m excited to see how the final version will be received.This sounds great. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Rob Clark <rob1weld at aol.com> wrote:> > 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? > > Yes. > > > 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)." > > ... > > It''s a Wiki, please fix it.itg changed already but it is a protected page that cannot be edited. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:> Rob Clark <rob1weld at aol.com> wrote: > > >>> 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)." >>> ... >>> >> It''s a Wiki, please fix it. >> > > itg changed already but it is a protected page that cannot be edited. >If you look at the history, one of the DTrace authors fixed it, but it looks like someone at RedHat seems to have decided they know DTrace better than one of the DTrace authors, and removed the DTrace correction. -- Andrew
przemolicc at poczta.fm
2009-Jan-21 10:27 UTC
[dtrace-discuss] Systemtap and Dtrace Comparison
On Wed, Jan 21, 2009 at 10:19:20AM +0000, Andrew Gabriel wrote:> Joerg Schilling wrote: > > Rob Clark <rob1weld at aol.com> wrote: > > > > > >>> 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)." > >>> ... > >>> > >> It''s a Wiki, please fix it. > >> > > > > itg changed already but it is a protected page that cannot be edited. > > > > If you look at the history, one of the DTrace authors fixed it, but it > looks like someone at RedHat seems to have decided they know DTrace > better than one of the DTrace authors, and removed the DTrace correction.How about creating similar comparison at wikis.sun.com ? Regards Przemyslaw Bak (przemol) -- http://przemol.blogspot.com/ ----------------------------------------------------------------------- Promocja w Speak Up. Kwartal angielskiego za darmo. 3 miesiace nauki gratis. Sprawdz teraz! >> http://link.interia.pl/f2019
Andrew Gabriel <agabriel at opensolaris.org> wrote:> > itg changed already but it is a protected page that cannot be edited. > > > > If you look at the history, one of the DTrace authors fixed it, but it > looks like someone at RedHat seems to have decided they know DTrace > better than one of the DTrace authors, and removed the DTrace correction.I noticed this already ;-) BTW: it is "funy" to see that every time CDDL and GPL are affected, some people do the same silly kind of wiki edit as you can see with cdrtools and some non-open people from the Linux camp. As I on the other side have very good relations to other OSS people in case there is a face to face meetin, it would be of interest for me to know whether the redhat person in question personally knows Dtrace people. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
In the table they claim: probe arbitrary statements in code symbolically (function entry, exit, interior, source code co-ordinates): yes (using debugging information) If that is true than they are a bit ahead in this area. I am really missing it in dtrace. Having this it would make dtrace user-land instrumentation even more powerful as It would allow to implement for example API monitor in few D lines. Are there any plans to implement it in dtrace? Remek On Wed, Jan 21, 2009 at 6:14 AM, Rob Clark <rob1weld at aol.com> wrote:>> 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? > > Yes. > >> 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)." >> ... > > It''s a Wiki, please fix it. > >> ... >> 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." > > If they have a feature that we do not then let us add it and be way ahead. > > Rob > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
> probe arbitrary statements in code symbolically (function entry, exit, > interior, source code co-ordinates): > yes (using debugging information) > > If that is true than they are a bit ahead in this area. I am really > missing it in dtrace. > Having this it would make dtrace user-land instrumentation even more powerful as > It would allow to implement for example API monitor in few D lines. > > Are there any plans to implement it in dtrace?We know that there are a few user-land improvements that would be nice to have (typing for example). I''m not completely sure what you would like to do though. Can you post an example? Jon.> Remek > > On Wed, Jan 21, 2009 at 6:14 AM, Rob Clark <rob1weld at aol.com> wrote: > >>> 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? >>> >> Yes. >> >> >>> 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)." >>> ... >>> >> It''s a Wiki, please fix it. >> >> >>> ... >>> 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." >>> >> If they have a feature that we do not then let us add it and be way ahead. >> >> Rob >> -- >> This message posted from opensolaris.org >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> >> > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
First thing that crossed my mind: We provide application to our customers and we provide support for it. When we release new version there are usually issues reported by customer. After some time I''ve realized that most of the issues (let''s say 50%) will appear (or let''s say affect) function''s parameters on some level of execution. Right now we have tracing macros directly compiled into our application for each function''s return/exit which logs function parameters as well as function name. By observing it I am usually able to quickly locate culprit of the issue. Problem is that we have to maintain all those tracing macros in the code. With dtrace I am able to get only function''s name (as it is in ABI) with one general "pid$1:::entry". As per my understanding there is no way to define function parameters logging generally.I would need to let''s say include header file with function''s prototypes and manually create probe for each function. To have better idea there is an application which I have tried which does similar thing on windows platform: www.autodebug.com. Remek On Wed, Jan 21, 2009 at 1:01 PM, Jon Haslam <Jonathan.Haslam at sun.com> wrote:> >> probe arbitrary statements in code symbolically (function entry, exit, >> interior, source code co-ordinates): >> yes (using debugging information) >> >> If that is true than they are a bit ahead in this area. I am really >> missing it in dtrace. >> Having this it would make dtrace user-land instrumentation even more >> powerful as >> It would allow to implement for example API monitor in few D lines. >> >> Are there any plans to implement it in dtrace? > > We know that there are a few user-land improvements that > would be nice to have (typing for example). I''m not completely > sure what you would like to do though. Can you post an example? > > Jon. > >> Remek >> >> On Wed, Jan 21, 2009 at 6:14 AM, Rob Clark <rob1weld at aol.com> wrote: >> >>>> >>>> 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? >>>> >>> >>> Yes. >>> >>> >>>> >>>> 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)." >>>> ... >>>> >>> >>> It''s a Wiki, please fix it. >>> >>> >>>> >>>> ... >>>> 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." >>>> >>> >>> If they have a feature that we do not then let us add it and be way >>> ahead. >>> >>> Rob >>> -- >>> This message posted from opensolaris.org >>> _______________________________________________ >>> dtrace-discuss mailing list >>> dtrace-discuss at opensolaris.org >>> >>> >> >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> > >
Yes, having user-land type information would allow you to do what you want here. As I said, it''s something we know users would like but it would be a piece of work to implement. Jon.> First thing that crossed my mind: We provide application to our customers > and we provide support for it. When we release new version there are usually > issues reported by customer. After some time I''ve realized that most of > the issues (let''s say 50%) will appear (or let''s say affect) > function''s parameters > on some level of execution. Right now we have tracing macros directly > compiled into our application for each function''s return/exit which > logs function > parameters as well as function name. By observing it I am usually able > to quickly locate > culprit of the issue. Problem is that we have to maintain all those > tracing macros > in the code. With dtrace I am able to get only function''s name (as it > is in ABI) > with one general "pid$1:::entry". As per my understanding there is no > way to define > function parameters logging generally.I would need to let''s say > include header file > with function''s prototypes and manually create probe for each > function. To have > better idea there is an application which I have tried which does > similar thing on > windows platform: www.autodebug.com. > > Remek > > On Wed, Jan 21, 2009 at 1:01 PM, Jon Haslam <Jonathan.Haslam at sun.com> wrote: >>> probe arbitrary statements in code symbolically (function entry, exit, >>> interior, source code co-ordinates): >>> yes (using debugging information) >>> >>> If that is true than they are a bit ahead in this area. I am really >>> missing it in dtrace. >>> Having this it would make dtrace user-land instrumentation even more >>> powerful as >>> It would allow to implement for example API monitor in few D lines. >>> >>> Are there any plans to implement it in dtrace? >> We know that there are a few user-land improvements that >> would be nice to have (typing for example). I''m not completely >> sure what you would like to do though. Can you post an example? >> >> Jon. >> >>> Remek >>> >>> On Wed, Jan 21, 2009 at 6:14 AM, Rob Clark <rob1weld at aol.com> wrote: >>> >>>>> 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? >>>>> >>>> Yes. >>>> >>>> >>>>> 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)." >>>>> ... >>>>> >>>> It''s a Wiki, please fix it. >>>> >>>> >>>>> ... >>>>> 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." >>>>> >>>> If they have a feature that we do not then let us add it and be way >>>> ahead. >>>> >>>> Rob >>>> -- >>>> This message posted from opensolaris.org >>>> _______________________________________________ >>>> dtrace-discuss mailing list >>>> dtrace-discuss at opensolaris.org >>>> >>>> >>>> >>> _______________________________________________ >>> dtrace-discuss mailing list >>> dtrace-discuss at opensolaris.org >>> >>> >> > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
On Wed, Jan 21, 2009 at 10:19:20AM +0000, Andrew Gabriel wrote:> Joerg Schilling wrote: > > Rob Clark <rob1weld at aol.com> wrote: > > > > > >>> 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)." > >>> ... > >>> > >> It''s a Wiki, please fix it. > >> > > > > itg changed already but it is a protected page that cannot be edited. > > > > If you look at the history, one of the DTrace authors fixed it, but it > looks like someone at RedHat seems to have decided they know DTrace > better than one of the DTrace authors, and removed the DTrace correction.Yes, there''s quite a bit of history here. ;) Suffice it to say that SystemTap and DTrace differ at profound, architectural levels. And while it would be ungentlemanly to call them "clowns", it''s a struggle to come up with a similarly apt label that is as succinct. And lest our sentiment be written off as partisanship, note that we aren''t the only ones who believe that SystemTap is a fiasco; see Ted Tso''s recent reproach of the project on the SystemTap mailing list: http://sourceware.org/ml/systemtap/2009-q1/msg00083.html Those seeking details on the two technologies should consult Stephen O''Grady''s two blog entries (and accompanying comments) on the topic: http://redmonk.com/sogrady/2006/04/07/linux-responds-to-dtrace-systemtap-on-tap/ http://redmonk.com/sogrady/2008/07/01/dtrace-vs-systemtap-redux/ Always a gentleman, Bryan -------------------------------------------------------------------------- Bryan Cantrill, Sun Microsystems Fishworks. http://blogs.sun.com/bmc