On Tue, Apr 27, 2010 at 11:21 AM, Mark Phalan <mark.pha...@sun.com> wrote:
> On Tue, 2010-04-27 at 11:14 -0400, Chad Mynhier wrote:
>>
>> The problem here is the wildcard and the use of args[]. DTrace has no
>> way of knowing that every one of your wildcarded probes (including
>> those that might not exist when you invoke DTrace) has exactly the
>> same argument types, so it bails.
>
> I guess I don't understand how it works but surely it should know it
> from the provider.d file. How does it do it for the kernel - CTF data?
No, you have the same problem with kernel probes. DTrace can get the
type data via CTF, and it does for the args[] array. It's entirely
possible that those probes matched by the wildcard have exactly the
same number of types and arguments, in which case DTrace could simply
verify that you're using args[0] correctly. But DTrace has no way of
knowing that some kernel module (or library, in the USDT case) that
gets loaded later won't have different argument types. In order to
avoid the problem of running a D script that becomes incorrect via a
modload or dlopen(), DTrace flags the error at compile time.
>
>>
>> You'd need to use arg0 and explicitly cast it to the type you want.
>
> Yeah, but thats messy :(
>
Your other option is not to use the wildcard but rather specify the
probes individually. For example, the following fails:
# dtrace -n 'fbt::read*:ent...@[args[0]] = count()}'
dtrace: invalid probe specifier fbt::read*:ent...@[args[0]] =
count()}: in action list: args[ ] may not be referenced because probe
description fbt::read*:entry matches an unstable set of probes
#
But this works:
# dtrace -n 'fbt::read:entry,fbt::readv:ent...@[args[0]] = count()}'
dtrace: description 'fbt::read:entry,fbt::readv:entry' matched 2 probes
^C
11 2
41 2
4 3
47 14
35 48
22 81
#
Chad
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
