[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-dtrace-discuss
Subject:    Re: [dtrace-discuss] wildcarding USDT probes
From:       Mark Phalan <Mark.Phalan () Sun ! COM>
Date:       2010-04-27 15:42:28
Message-ID: 1272382948.4332.18.camel () phalan
[Download RAW message or body]

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

_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]