How do I query an application to see if it supports any USDT probe points?
Hi Dan: I typically do dtrace -l -n *pid::: The USDT probes are pre-initialized(may not be the right technical term) unlike the pid probes. Note: I also see plockstat and libCrun probes showing up in the listing. And I assume if you have used the pid provider on the process the pid probes will show up as well. -Angelo On Jan 29, 2008, at 2:57 AM, Dan Mick wrote:> How do I query an application to see if it supports any USDT probe > points? > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
Angelo Rajadurai wrote:> Hi Dan: > > I typically do > > dtrace -l -n *pid::: > > The USDT probes are pre-initialized(may not be the right technical term) > unlike the pid probes.So, it''s a system-wide query?> Note: I also see plockstat and libCrun probes showing up in the listing.I do not see any probes resulting from that literal command, which confuses me.> And I assume if you have used the pid provider on the process the pid > probes will show up as well. > > -Angelo > > On Jan 29, 2008, at 2:57 AM, Dan Mick wrote: > >> How do I query an application to see if it supports any USDT probe >> points? >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org
On Jan 29, 2008, at 9:31 PM, Dan Mick wrote:> Angelo Rajadurai wrote: >> Hi Dan: >> I typically do >> dtrace -l -n *pid::: >> The USDT probes are pre-initialized(may not be the right technical >> term) >> unlike the pid probes. > > So, it''s a system-wide query? > >> Note: I also see plockstat and libCrun probes showing up in the >> listing. > > I do not see any probes resulting from that literal command, which > confuses me.Sorry for not being specific. replace pid with the process id of the process of interest. For example if the pid of the process you are interested in is 1234 then the command line would be dtrace -l -n *1234::: Hope this explains. Angelo> > >> And I assume if you have used the pid provider on the process the pid >> probes will show up as well. >> -Angelo >> On Jan 29, 2008, at 2:57 AM, Dan Mick wrote: >>> How do I query an application to see if it supports any USDT probe >>> points? >>> _______________________________________________ >>> dtrace-discuss mailing list >>> dtrace-discuss at opensolaris.org >
> For example if the pid of the process you are > interested in is 1234 then the command line would be > > dtrace -l -n *1234:::Ah. Thanks. Yes, that shows libCrun and plockstat probes, as well as some extras that are app-specific (javascript, in Firefox 3.0b3pre). But I don''t see any "moz*" probes, which I expected. Now, I can ask why with authority. Thanks. (So, apparently, the application does some .init time stuff to "register" the probes with the DTrace framework, which allocates the provider name including the PID. I see. I think I''ll build Bart''s toy app and dissect it a bit.
> I typically do > > dtrace -l -n *pid:::That''s interesting to know because a change we''re planning is going to make it so that that invocation will no longer do what you want. The change that''s being made is so that a probe description like p*123 will match both pid probes and plockstat probes. You will, however, be able to list USDT probes without creating pid probes by doing something like: dtrace -l -n *12[3]::: Would it be worth having a special flag to dtrace(1M) which could list the USDT probes (or providers) for a running process or executable binary? Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
On Jan 29, 2008, at 10:21 PM, Adam Leventhal wrote:>> I typically do >> >> dtrace -l -n *pid::: > > That''s interesting to know because a change we''re planning is going > to make > it so that that invocation will no longer do what you want. The change > that''s being made is so that a probe description like p*123 will > match both > pid probes and plockstat probes. You will, however, be able to list > USDT > probes without creating pid probes by doing something like: >Adam: It would be wonderful to have dtrace -l -n *1234::: show all the pid probes. Right now I need to do a dtrace -n *1234::::entry -n *1234:::return and wait till dtrace instruments the process before I can see the probes. If I want to see just the USDT probes and not the pid probes I can always use grep -v dtrace -l *1234::: | grep -v pid would work nicely. Adding a command line option for just USDT probes seems like a overkill to me, but others may disagree. In many cases I know the name of the USDT provider so its easy to get to it. For example hotspot*:::gc-start or dvm*:::gc-start seem to do the right thing. Also if I''m looking for a list of providers I can always do dtrace -l | cut -f 2 -d \ | sort -u -Angelo> dtrace -l -n *12[3]::: > > Would it be worth having a special flag to dtrace(1M) which could list > the USDT probes (or providers) for a running process or executable > binary? > > Adam > > -- > Adam Leventhal, Fishworks http://blogs.sun.com/ahl
On Tue, Jan 29, 2008 at 10:47:57PM -0500, Angelo Rajadurai wrote:> It would be wonderful to have dtrace -l -n *1234::: show all the pid > probes.I should have been clearer. Today, that will show existing pid probes. After the fix it will _create_ new pid probes so *1234::: will fail as it tries to create a probe for every instruction in the process. It seems like it would be useful to be able to view the USDT probes for a non-running executable. What do people think? Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
On Jan 30, 2008, at 10:08 AM, Adam Leventhal wrote:> On Tue, Jan 29, 2008 at 10:47:57PM -0500, Angelo Rajadurai wrote: >> It would be wonderful to have dtrace -l -n *1234::: show all the pid >> probes. > > I should have been clearer. Today, that will show existing pid probes. > After the fix it will _create_ new pid probes so *1234::: will fail > as it > tries to create a probe for every instruction in the process. > > It seems like it would be useful to be able to view the USDT probes > for > a non-running executable. What do people think?We''ve had several requests for this feature. An interesting question we''ve debated is should such a feature include probes from libraries? I.E, user does: dtrace_list_probes ./someApplicationTheyCareAbout they get: "Zero probes found" but they expected to see at least plockstat probes, maybe some CoreData probes, and so on. James M
On Wed, Jan 30, 2008 at 11:05:04AM -0800, James McIlree wrote:> We''ve had several requests for this feature. > > An interesting question we''ve debated is should such > a feature include probes from libraries? > > I.E, user does: > > dtrace_list_probes ./someApplicationTheyCareAbout > > they get: > > "Zero probes found" > > but they expected to see at least plockstat probes, > maybe some CoreData probes, and so on.It seems like we should probably navigate the library dependencies -- good point. If you''re already thinking about working on this, that would be great, but please send out a proposal before you squat on a particular option character as we have some plans for various ones... - ahl -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
On Jan 30, 2008, at 11:19 AM, Adam Leventhal wrote:> On Wed, Jan 30, 2008 at 11:05:04AM -0800, James McIlree wrote: >> We''ve had several requests for this feature. >> >> An interesting question we''ve debated is should such >> a feature include probes from libraries? >> >> I.E, user does: >> >> dtrace_list_probes ./someApplicationTheyCareAbout >> >> they get: >> >> "Zero probes found" >> >> but they expected to see at least plockstat probes, >> maybe some CoreData probes, and so on. > > It seems like we should probably navigate the library dependencies > -- good > point. > > If you''re already thinking about working on this, that would be > great, but > please send out a proposal before you squat on a particular option > character > as we have some plans for various ones...Not to worry, I''m positive I won''t have time to look at this soon :-). Along those lines, though, it feels like the dtrace command might be getting a bit overloaded. I''m sure I''m forgetting some, but I know dtrace is at least a linker, a header file generator, a compiler, and now possibly an object file parser with DOF pretty printing. Is there any thinking of splitting these functions into separate commands? James M
> Along those lines, though, it feels like the dtrace command might > be getting a bit overloaded. > > I''m sure I''m forgetting some, but I know dtrace is at least a linker, > a header file generator, a compiler, and now possibly an object file > parser with DOF pretty printing.We often joked that we were reimplementing all of computing inside of the DTrace framework.> Is there any thinking of splitting these functions into separate > commands?Never! Or at least not until we''re forced to use unicode command-line options. Though users or ports should feel free to sequester specific functionality in simple wrapper scripts. Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
Adam Leventhal wrote:> On Tue, Jan 29, 2008 at 10:47:57PM -0500, Angelo Rajadurai wrote: >> It would be wonderful to have dtrace -l -n *1234::: show all the pid >> probes. > > I should have been clearer. Today, that will show existing pid probes. > After the fix it will _create_ new pid probes so *1234::: will fail as it > tries to create a probe for every instruction in the process. > > It seems like it would be useful to be able to view the USDT probes for > a non-running executable. What do people think?I think it would be useful (especially for applications that can''t start), and it would be cool if it were as parallel as possible for running vs. not-running applications. DTrace is a very "discover things without knowing anything"-capable application, so "a list of probes and providers" may be the secret to narrowing down a behavior in something for which you don''t have source or experience.