If it matters, I am using Mac OS X 10.6.x. Let''s say that I open a terminal window, enabled a few probes, and start collecting data. From a different terminal window can I ask DTrace what probes have been enabled? If so, how? Thank you.
Hey Eric,
There''s not a great way to do it, but you can use a tool like mdb(1)
on Solaris, or a simple DTrace script:
---8<--- dtrace_probes.d ---8<---
#!/usr/sbin/dtrace -s
#pragma D option quiet
int i;
tick-100
/i >= `dtrace_nprobes/
{
exit(0);
}
tick-100
{ printf("%4d %10s %20s %20s %10s %s\n", i,
stringof(`dtrace_probes[i]->dtpr_provider->dtpv_name),
stringof(`dtrace_probes[i]->dtpr_mod),
stringof(`dtrace_probes[i]->dtpr_func),
stringof(`dtrace_probes[i]->dtpr_name),
`dtrace_probes[i]->dtpr_ecb != NULL ? "enabled" :
"disabled");
i++
}
---8<--- dtrace_probes.d ---8<---
0 dtrace BEGIN disabled
1 dtrace END disabled
2 dtrace ERROR enabled
3 python589 libpython2.6.so.1.0 PyEval_EvalFrameEx
function-entry disabled
4 python589 libpython2.6.so.1.0 dtrace_entry
function-entry disabled
Unfortunately this doesn''t work on Mac OS X:
# dtrace -n ''BEGIN{ trace(`dtrace_nprobes); }''
dtrace: invalid probe specifier BEGIN{ trace(`dtrace_nprobes); }: in
action list: failed to resolve `dtrace_nprobes: Unknown symbol name
Some kernel symbols seem to be available; perhaps someone more
familiar with Mac OS X can get this script running over there.
Adam
On Tue, Jun 21, 2011 at 5:01 AM, Eric Gorr <mailist at ericgorr.net>
wrote:> If it matters, I am using Mac OS X 10.6.x.
>
> Let''s say that I open a terminal window, enabled a few probes, and
start collecting data.
>
> From a different terminal window can I ask DTrace what probes have been
enabled? If so, how?
>
> Thank you.
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>
--
Adam Leventhal, Delphix
http://dtrace.org/blogs/ahl
275 Middlefield Road, Suite 50
Menlo Park, CA 94025
http://www.delphix.com
Thanks. This is quite interesting. I wonder where one goes to learn about what kernel symbols are available in Mac OS X...? On Jun 21, 2011, at 12:17 PM, Adam Leventhal <ahl at delphix.com> wrote:> Hey Eric, > > There''s not a great way to do it, but you can use a tool like mdb(1) > on Solaris, or a simple DTrace script: > > ---8<--- dtrace_probes.d ---8<--- > > #!/usr/sbin/dtrace -s > > #pragma D option quiet > > int i; > > tick-100 > /i >= `dtrace_nprobes/ > { > exit(0); > } > > tick-100 > { printf("%4d %10s %20s %20s %10s %s\n", i, > stringof(`dtrace_probes[i]->dtpr_provider->dtpv_name), > stringof(`dtrace_probes[i]->dtpr_mod), > stringof(`dtrace_probes[i]->dtpr_func), > stringof(`dtrace_probes[i]->dtpr_name), > `dtrace_probes[i]->dtpr_ecb != NULL ? "enabled" : "disabled"); > i++ > } > > ---8<--- dtrace_probes.d ---8<--- > > 0 dtrace BEGIN disabled > 1 dtrace END disabled > 2 dtrace ERROR enabled > 3 python589 libpython2.6.so.1.0 PyEval_EvalFrameEx > function-entry disabled > 4 python589 libpython2.6.so.1.0 dtrace_entry > function-entry disabled > > Unfortunately this doesn''t work on Mac OS X: > > # dtrace -n ''BEGIN{ trace(`dtrace_nprobes); }'' > dtrace: invalid probe specifier BEGIN{ trace(`dtrace_nprobes); }: in > action list: failed to resolve `dtrace_nprobes: Unknown symbol name > > Some kernel symbols seem to be available; perhaps someone more > familiar with Mac OS X can get this script running over there. > > Adam > > On Tue, Jun 21, 2011 at 5:01 AM, Eric Gorr <mailist at ericgorr.net> wrote: >> If it matters, I am using Mac OS X 10.6.x. >> >> Let''s say that I open a terminal window, enabled a few probes, and start collecting data. >> >> From a different terminal window can I ask DTrace what probes have been enabled? If so, how? >> >> Thank you. >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> > > > > -- > Adam Leventhal, Delphix > http://dtrace.org/blogs/ahl > > 275 Middlefield Road, Suite 50 > Menlo Park, CA 94025 > http://www.delphix.com
Well, with a little research, I believe I was able to find the answer to determine what was available in Mac OS X. Just execute: nm -j /mach_kernel and, of course, one can do: nm -j /mach_kernel | grep dtrace to see which ones are dtrace related. As expected, dtrace_nprobes & dtrace_probes aren''t in the list. I didn''t see anything that looked promising, but perhaps someone else may be able to spot something. I am wondering...let''s say I did see something that looked promising, how would I go about determining the structure? How would I know that I could do <some var>->something and see some meaningful data? How might someone who didn''t already know, know that dtpr_name was part of dtrace_probes[i] - i.e. that one could do `dtrace_probes[i]->dtpr_name? Is the only way by inspecting the kernel code itself or is thing kind of thing documented somewhere? Thank you. On Jun 21, 2011, at 4:12 PM, Eric Gorr wrote:> Thanks. This is quite interesting. I wonder where one goes to learn about what kernel symbols are available in Mac OS X...? > > On Jun 21, 2011, at 12:17 PM, Adam Leventhal <ahl at delphix.com> wrote: > >> Hey Eric, >> >> There''s not a great way to do it, but you can use a tool like mdb(1) >> on Solaris, or a simple DTrace script: >> >> ---8<--- dtrace_probes.d ---8<--- >> >> #!/usr/sbin/dtrace -s >> >> #pragma D option quiet >> >> int i; >> >> tick-100 >> /i >= `dtrace_nprobes/ >> { >> exit(0); >> } >> >> tick-100 >> { printf("%4d %10s %20s %20s %10s %s\n", i, >> stringof(`dtrace_probes[i]->dtpr_provider->dtpv_name), >> stringof(`dtrace_probes[i]->dtpr_mod), >> stringof(`dtrace_probes[i]->dtpr_func), >> stringof(`dtrace_probes[i]->dtpr_name), >> `dtrace_probes[i]->dtpr_ecb != NULL ? "enabled" : "disabled"); >> i++ >> } >> >> ---8<--- dtrace_probes.d ---8<--- >> >> 0 dtrace BEGIN disabled >> 1 dtrace END disabled >> 2 dtrace ERROR enabled >> 3 python589 libpython2.6.so.1.0 PyEval_EvalFrameEx >> function-entry disabled >> 4 python589 libpython2.6.so.1.0 dtrace_entry >> function-entry disabled >> >> Unfortunately this doesn''t work on Mac OS X: >> >> # dtrace -n ''BEGIN{ trace(`dtrace_nprobes); }'' >> dtrace: invalid probe specifier BEGIN{ trace(`dtrace_nprobes); }: in >> action list: failed to resolve `dtrace_nprobes: Unknown symbol name >> >> Some kernel symbols seem to be available; perhaps someone more >> familiar with Mac OS X can get this script running over there. >> >> Adam >> >> On Tue, Jun 21, 2011 at 5:01 AM, Eric Gorr <mailist at ericgorr.net> wrote: >>> If it matters, I am using Mac OS X 10.6.x. >>> >>> Let''s say that I open a terminal window, enabled a few probes, and start collecting data. >>> >>> From a different terminal window can I ask DTrace what probes have been enabled? If so, how? >>> >>> Thank you. >>> _______________________________________________ >>> dtrace-discuss mailing list >>> dtrace-discuss at opensolaris.org >>> >> >> >> >> -- >> Adam Leventhal, Delphix >> http://dtrace.org/blogs/ahl >> >> 275 Middlefield Road, Suite 50 >> Menlo Park, CA 94025 >> http://www.delphix.com > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
Hey Eric,> to see which ones are dtrace related. As expected, dtrace_nprobes & dtrace_probes aren''t in the list. I didn''t see anything that looked promising, but perhaps someone else may be able to spot something.Very interesting, but it looks like Apple is doing something cagey with kernel symbols: # dtrace -n BEGIN''{ trace(`dtrace_probe); }'' dtrace: description ''BEGIN'' matched 1 probe dtrace: error on enabled probe ID 1 (ID 1: dtrace:::BEGIN): invalid alignment (0xffffff80004de015) in action #1 at DIF offset 4> I am wondering...let''s say I did see something that looked promising, how would I go about determining the structure? How would I know that I could do <some var>->something and see some meaningful data? How might someone who didn''t already know, know that dtpr_name was part of dtrace_probes[i] - i.e. that one could do `dtrace_probes[i]->dtpr_name? Is the only way by inspecting the kernel code itself or is thing kind of thing documented somewhere?I''m doing this by looking at the illumos source code at http://src.illumos.org/. I knew that dtrace_probes and dtrace_nprobes were the relevant variables (from my part in developing DTrace), but you might have been able to figure that out by looking at the code for dtrace_probe(): http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/dtrace/dtrace.c#5610 /* * If you''re looking for the epicenter of DTrace, you just found it. This * is the function called by the provider to fire a probe -- from which all * subsequent probe-context DTrace activity emanates. */ void dtrace_probe(dtrace_id_t id, uintptr_t arg0, uintptr_t arg1, uintptr_t arg2, uintptr_t arg3, uintptr_t arg4) { ... In there you can find the variable dtrace_probes and dtrace_nprobes, and click through to find their datatypes and those type definitions. Adam -- Adam Leventhal, Delphix http://dtrace.org/blogs/ahl 275 Middlefield Road, Suite 50 Menlo Park, CA 94025 http://www.delphix.com
On Jun 22, 2011, at 11:19 AM, Adam Leventhal wrote:> Hey Eric, > >> to see which ones are dtrace related. As expected, dtrace_nprobes & dtrace_probes aren''t in the list. I didn''t see anything that looked promising, but perhaps someone else may be able to spot something. > > Very interesting, but it looks like Apple is doing something cagey > with kernel symbols: >Oh my, I can see the headlines now "Apple cages DTrace" :-} This appears to be a *BUG* in the shipping MacOS X 10.6.n. Please file a bug report through your usual channels. N.B., this is fixed in the WWDC build of Mac OS X 10.7: $ sudo dtrace -n BEGIN''{ trace(`dtrace_probe); }'' Password: dtrace: description ''BEGIN'' matched 1 probe CPU ID FUNCTION:NAME 1 1 :BEGIN 6215344901283465301 SCP -- Steve Peters scp at mac.com
Hey Steve, Great to see your name pop up on DTrace discuss!>> Very interesting, but it looks like Apple is doing something cagey >> with kernel symbols: >> > Oh my, I can see the headlines now "Apple cages DTrace" ?:-}Someday I''ll make it up to you ;-)> This appears to be a *BUG* in the shipping MacOS X 10.6.n. > Please file a bug report through your usual channels.Good to know it''s a bug. My usual channels are to mail you and James... what''s channel that you''d like DTrace community members to use?> N.B., this is fixed in the WWDC build of Mac OS X 10.7: > > $ sudo dtrace -n BEGIN''{ trace(`dtrace_probe); }'' > Password: > dtrace: description ''BEGIN'' matched 1 probe > CPU ? ? ID ? ? ? ? ? ? ? ? ? ?FUNCTION:NAME > ?1 ? ? ?1 ? ? ? ? ? ? ? ? ? ? ? ? ? :BEGIN ?6215344901283465301Awesome. Steve, while we have you, can you explain why the dtrace_probes and dtrace_nprobes variables aren''t visible? Or are they also available on 10.7? I tried to write a version of the script that inferred the location of dtrace_probes from disassembly of dtrace_probe(). Will that work on 10.7? ---8<--- #!/usr/sbin/dtrace -s #pragma D option quiet int i; tick-100 { /* this->p = `dtrace_probes */ this->p = (dtrace_probe_t **)((uintptr_t)`dtrace_probe + 0x38 + 0x003ba004); printf("%4d %10s %20s %20s %10s %s\n", i, stringof(this->p[i]->dtpr_provider->dtpv_name), stringof(this->p[i]->dtpr_mod), stringof(this->p[i]->dtpr_func), stringof(this->p[i]->dtpr_name), this->p[i]->dtpr_ecb != NULL ? "enabled" : "disabled"); i++ } ---8<--- As always, thanks for your help. Glad to see that DTrace is still kicking at Apple. Adam -- Adam Leventhal, Delphix http://dtrace.org/blogs/ahl 275 Middlefield Road, Suite 50 Menlo Park, CA 94025 http://www.delphix.com
On Jun 22, 2011, at 11:40 AM, Adam Leventhal wrote:> Good to know it''s a bug. My usual channels are to mail you and > James... what''s channel that you''d like DTrace community members to > use?In general, anyone can submit a bug against anything that Apple ships by following the instructions on the following page. <http://developer.apple.com/bugreporter/> SCP -- Steve Peters scp at mac.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20110622/f2c4c0ed/attachment.html>
So, I''m curious if you had an answer to the question of how one might be able to determine what probes are enabled...? If this is not possible on Mac OS x, I will go ahead and file a bug report. Thank you On Jun 22, 2011, at 3:14 PM, Steve Peters <scp at mac.com> wrote:> > On Jun 22, 2011, at 11:40 AM, Adam Leventhal wrote: > >> Good to know it''s a bug. My usual channels are to mail you and >> James... what''s channel that you''d like DTrace community members to >> use? > In general, anyone can submit a bug against anything that Apple ships > by following the instructions on the following page. > > <http://developer.apple.com/bugreporter/> > > SCP > -- > Steve Peters > scp at mac.com > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20110622/4536f37f/attachment.html>
On Jun 22, 2011, at 11:40 AM, Adam Leventhal wrote:> Steve, while we have you, can you explain why the dtrace_probes and > dtrace_nprobes variables aren''t visible?Adam, It looks like our ctf_convert and/or ctf_merge casts (sic) a blind eye on static data objects. If you''d like to file a bug ... SCP -- Steve Peters scp at mac.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20110623/6a3c15ef/attachment.html>
Bug filed: rdar://9662467 On Jun 22, 2011, at 11:40 AM, Adam Leventhal wrote:> Steve, while we have you, can you explain why the dtrace_probes and > dtrace_nprobes variables aren''t visible?Adam, It looks like our ctf_convert and/or ctf_merge casts (sic) a blind eye on static data objects. If you''d like to file a bug ... SCP -- Steve Peters