Can I ask what probes are enabled?

[Eric Gorr]

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.

[Adam Leventhal]

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

Post by Eric Gorr
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

[Eric Gorr]

Thanks. This is quite interesting. I wonder where one goes to learn about what kernel symbols are available in Mac OS X...?

Post by Adam Leventhal
Hey Eric,
There's not a great way to do it, but you can use a tool like mdb(1)
---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
# 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

Post by Eric Gorr
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

--
Adam Leventhal, Delphix
http://dtrace.org/blogs/ahl
275 Middlefield Road, Suite 50
Menlo Park, CA 94025
http://www.delphix.com

[Eric Gorr]

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.

Post by Eric Gorr
Thanks. This is quite interesting. I wonder where one goes to learn about what kernel symbols are available in Mac OS X...?

Post by Adam Leventhal
Hey Eric,
There's not a great way to do it, but you can use a tool like mdb(1)
---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
# 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

Post by Eric Gorr
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

--
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

[Adam Leventhal]

Hey Eric,

Post by Eric Gorr
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

Post by Eric Gorr
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

[Steve Peters]

Post by Adam Leventhal
Hey Eric,

Post by Eric Gorr
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

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-***@public.gmane.org

[Adam Leventhal]

Hey Steve,

Great to see your name pop up on DTrace discuss!

Post by Adam Leventhal
Very interesting, but it looks like Apple is doing something cagey

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?

$ sudo dtrace -n BEGIN'{ trace(`dtrace_probe); }'
dtrace: description 'BEGIN' matched 1 probe
CPU     ID                    FUNCTION:NAME
 1      1                           :BEGIN  6215344901283465301

Awesome.

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

[Steve Peters]

Post by Adam Leventhal
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-***@public.gmane.org

[Eric Gorr]

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

Post by Steve Peters

Post by Adam Leventhal
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

[Eric Gorr]

Bug filed: rdar://9662467

Post by Adam Leventhal
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

[Steve Peters]

Post by Adam Leventhal
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-***@public.gmane.org