There is a new article in SDN web site: "Using DTrace to Demystify Watchpoints in the Sun Studio dbx Debugger" http://developers.sun.com/sunstudio/articles/demistify_watch_points.html __Nasser -- This message posted from opensolaris.org
Pierre-Olivier Gaillard
2007-Sep-13 15:52 UTC
[dtrace-discuss] DTrace and watchpoints article
Hi, I was wondering if there was a dtrace provider that uses the debug registers. I would like to trace all call to one or two user functions and gather a few statistics about the data they handle. This seems like a job for dtrace but I could not figure out what provider to use. Thank you for your help, Pierre-Olivier Gaillard On 8/17/07, Nasser Nouri <nasser.nouri at sun.com> wrote:> > There is a new article in SDN web site: > > "Using DTrace to Demystify Watchpoints in the Sun Studio dbx Debugger" > > http://developers.sun.com/sunstudio/articles/demistify_watch_points.html > > __Nasser > > > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070913/472f243f/attachment.html>
Pierre-Olivier Gaillard wrote:> Hi, > > I was wondering if there was a dtrace provider that uses the debug > registers.No, but...> I would like to trace all call to one or two user functions > and gather a few statistics about the data they handle. > This seems like a job for dtrace but I could not figure out what > provider to use....the pid provider should do just fine. With a "test" directory in the current directory, containing an entry "bin": dtrace -n pid\$target::strlen:entry -c "ls test" dtrace: description ''pid$target::strlen:entry'' matched 2 probes bin dtrace: pid 4037 has exited CPU ID FUNCTION:NAME 0 74985 strlen:entry 0 74985 strlen:entry> Thank you for your help, > > Pierre-Olivier Gaillard > > On 8/17/07, *Nasser Nouri* <nasser.nouri at sun.com > <mailto:nasser.nouri at sun.com>> wrote: > > There is a new article in SDN web site: > > "Using DTrace to Demystify Watchpoints in the Sun Studio dbx Debugger" > > http://developers.sun.com/sunstudio/articles/demistify_watch_points.html > > __Nasser > > > -- > This message posted from opensolaris.org <http://opensolaris.org> > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org <mailto:dtrace-discuss at opensolaris.org> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
Pierre-Olivier Gaillard
2007-Sep-13 19:00 UTC
[dtrace-discuss] DTrace and watchpoints article
Thanks a lot. But if it does not use the debug registers, does it mean it modifies the code on the fly to intercept the function call ? It looks like it from the fbt documentation which is supposed to apply to pid too. I wonder if using the debug registers would be any faster. They would cause lots of traps whereas the dtrace instrumentation might be very efficient and just write some data that can be collected later. Thanks again, -- Pierre-Olivier Gaillard On 9/13/07, Dan Mick <dan.mick at sun.com> wrote:> > Pierre-Olivier Gaillard wrote: > > Hi, > > > > I was wondering if there was a dtrace provider that uses the debug > > registers. > > No, but... > > > I would like to trace all call to one or two user functions > > and gather a few statistics about the data they handle. > > This seems like a job for dtrace but I could not figure out what > > provider to use. > > ...the pid provider should do just fine. With a "test" directory in > the current directory, containing an entry "bin": > > dtrace -n pid\$target::strlen:entry -c "ls test" > dtrace: description ''pid$target::strlen:entry'' matched 2 probes > bin > dtrace: pid 4037 has exited > CPU ID FUNCTION:NAME > 0 74985 strlen:entry > 0 74985 strlen:entry > > > > Thank you for your help, > > > > Pierre-Olivier Gaillard > > > > On 8/17/07, *Nasser Nouri* <nasser.nouri at sun.com > > <mailto:nasser.nouri at sun.com>> wrote: > > > > There is a new article in SDN web site: > > > > "Using DTrace to Demystify Watchpoints in the Sun Studio dbx > Debugger" > > > > > http://developers.sun.com/sunstudio/articles/demistify_watch_points.html > > > > __Nasser > > > > > > -- > > This message posted from opensolaris.org <http://opensolaris.org> > > _______________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss at opensolaris.org <mailto: > dtrace-discuss at opensolaris.org> > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss at opensolaris.org > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070913/915d3a3a/attachment.html>
Pierre-Olivier Gaillard wrote:> Thanks a lot. > > But if it does not use the debug registers, does it mean it modifies the > code on the fly to intercept the function call ? It looks like it from > the fbt documentation which is supposed to apply to pid too.yes. It does that in kernel mode as well (fbt). That''s essentially the implementation of dtrace; it puts trap-causing sequences where you ask for them.> > I wonder if using the debug registers would be any faster. They would > cause lots of traps whereas the dtrace instrumentation might be very > efficient and just write some data that can be collected later.It''s possible, but there are very few of them, and they tend to be used by (surprise) debuggers. dtrace can have tens of thousands of probe points instrumented at once. And I doubt that the "take a debug trap" is much more efficient than "take whatever trap dtrace causes" (usually illegal-instruction on x86, I think), if at all...but the real killer is that the resources are so limited, and contended for anyway.> > Thanks again, > > -- > Pierre-Olivier Gaillard > > On 9/13/07, *Dan Mick* <dan.mick at sun.com <mailto:dan.mick at sun.com>> wrote: > > Pierre-Olivier Gaillard wrote: > > Hi, > > > > I was wondering if there was a dtrace provider that uses the debug > > registers. > > No, but... > > > I would like to trace all call to one or two user functions > > and gather a few statistics about the data they handle. > > This seems like a job for dtrace but I could not figure out what > > provider to use. > > ...the pid provider should do just fine. With a "test" directory in > the current directory, containing an entry "bin": > > dtrace -n pid\$target::strlen:entry -c "ls test" > dtrace: description ''pid$target::strlen:entry'' matched 2 probes > bin > dtrace: pid 4037 has exited > CPU ID FUNCTION:NAME > 0 74985 strlen:entry > 0 74985 strlen:entry > > > > Thank you for your help, > > > > Pierre-Olivier Gaillard > > > > On 8/17/07, *Nasser Nouri* <nasser.nouri at sun.com > <mailto:nasser.nouri at sun.com> > > <mailto:nasser.nouri at sun.com <mailto:nasser.nouri at sun.com>>> wrote: > > > > There is a new article in SDN web site: > > > > "Using DTrace to Demystify Watchpoints in the Sun Studio dbx > Debugger" > > > > > http://developers.sun.com/sunstudio/articles/demistify_watch_points.html > <http://developers.sun.com/sunstudio/articles/demistify_watch_points.html> > > > > __Nasser > > > > > > -- > > This message posted from opensolaris.org > <http://opensolaris.org> <http://opensolaris.org> > > _______________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss at opensolaris.org > <mailto:dtrace-discuss at opensolaris.org> <mailto: > dtrace-discuss at opensolaris.org <mailto:dtrace-discuss at opensolaris.org>> > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss at opensolaris.org > <mailto:dtrace-discuss at opensolaris.org> > >