Whenever I try to use a wildcard in my dtrace scripts with my USDT provider I get an error complaining that the set of probes is unstable. dtrace -n ''foo$target:::bar-* { printf("%d\n", args[0]->i); }'' -c /tmp/x dtrace: invalid probe specifier foo$target:::bar-* { printf("%d\n", args[0]->i); }: in action list: args[ ] may not be referenced because probe description foo4908:::bar-* matches an unstable set of probes The provider file looks like this: ############################# typedef struct foo_info { int i; } foo_info_t; typedef struct finfo { int i; } finfo_t; translator finfo_t <foo_info_t *P> { i = P->i; }; provider foo { probe bar__start(foo_info_t *i): (finfo_t i); probe bar__end(foo_info_t *i): (finfo_t i); }; #pragma D attributes Stable/Stable/Common provider foo provider #pragma D attributes Stable/Stable/Common provider foo module #pragma D attributes Stable/Stable/Common provider foo function #pragma D attributes Stable/Stable/Common provider foo name #pragma D attributes Stable/Stable/Common provider foo args ################################ The library support file: ################################ typedef struct foo_info { uint32_t i; } foo_info_t; typedef struct finfo { uint32_t i; } finfo_t; translator finfo_t <foo_info_t *P> { i = *((uint32_t *)(copyin((uintptr_t)&P->i, sizeof (uint32_t)))); }; ################################ The above is a contrived example but shows what I''m trying to do. How can I make my USDT probes suitable for wildcarding? Is this a bug? Thanks, -M
On Tue, Apr 27, 2010 at 11:00 AM, Mark Phalan <Mark.Phalan at sun.com> wrote:> > Whenever I try to use a wildcard in my dtrace scripts with my USDT > provider I get an error complaining that the set of probes is unstable. > > dtrace -n ''foo$target:::bar-* { printf("%d\n", args[0]->i); }'' -c /tmp/x > dtrace: invalid probe specifier foo$target:::bar-* { printf("%d\n", > args[0]->i); }: in action list: args[ ] may not be referenced because > probe description foo4908:::bar-* matches an unstable set of probesThe 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. You''d need to use arg0 and explicitly cast it to the type you want. Chad
On Tue, 2010-04-27 at 11:14 -0400, Chad Mynhier wrote:> On Tue, Apr 27, 2010 at 11:00 AM, Mark Phalan <Mark.Phalan at sun.com> wrote: > > > > Whenever I try to use a wildcard in my dtrace scripts with my USDT > > provider I get an error complaining that the set of probes is unstable. > > > > dtrace -n ''foo$target:::bar-* { printf("%d\n", args[0]->i); }'' -c /tmp/x > > dtrace: invalid probe specifier foo$target:::bar-* { printf("%d\n", > > args[0]->i); }: in action list: args[ ] may not be referenced because > > probe description foo4908:::bar-* matches an unstable set of probes > > 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?> > You''d need to use arg0 and explicitly cast it to the type you want.Yeah, but thats messy :( -M
On Tue, Apr 27, 2010 at 11:21 AM, Mark Phalan <Mark.Phalan at 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*:entry{@[args[0]] = count()}'' dtrace: invalid probe specifier fbt::read*:entry{@[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:entry{@[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
On Tue, 2010-04-27 at 11:37 -0400, Chad Mynhier wrote:> On Tue, Apr 27, 2010 at 11:21 AM, Mark Phalan <Mark.Phalan at 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.Ok that makes sense.> > > > >> > >> 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.Yes, this is something I do already but its a little more verbose. I can live with it though. Thanks, -M