Re: Writing tapset functions for multiple versions

[Felix Lu <flu at redhat dot com>]

----- Original Message -----
> From: "David Smith" <dsmith@redhat.com>
> To: "Felix Lu" <flu@redhat.com>, systemtap@sourceware.org
> Sent: Wednesday, 20 July, 2016 10:05:09 AM
> Subject: Re: Writing tapset functions for multiple versions
> 
> On 07/19/2016 04:06 PM, Felix Lu wrote:
> > This is a demonstration of writing functions for multiple
> > versions of a tapset.
> > 
> > Consider the scenario where multiple tapsets are installed, each targeting
> > a different version of some process/library. You might want to provide a
> > function f that is implemented differently for each version. It is possible
> > to create the functions f1 and f2, but this means that the users
> > can't create portable scripts that work with all versions. This can now
> > be done with function overloading in systemtap 3.0.
> > 
> > # version1.stp
> > function f() {
> >   if (pp() !~ "version1")
> >     next
> >   println("version1")
> > }
> > probe pp = process("version1/process").function("main") {}
> > 
> > # version2.stp
> > function f() {
> >   if (pp() !~ "version2")
> >     next
> >   println("version2")
> > }
> > probe pp = process("version2/process").function("main") {}
> > 
> > $ stap -I . -e 'probe pp {f()}' -c ./version1/process
> > version1
> > 
> > $ stap -I . -e 'probe pp {f()}' -c ./version2/process
> > version2
> > 
> > Based on the context of the probe, the correct function
> > is selected at run time.
> > 
> > The condition to select an overloaded function can be
> > arbitrary. In this case, we check the probe point that is triggered.
> 
> (One confusing thing about your example above is that you are using the
> 'pp' function, but you also have a probe called 'pp'. I think your
> example would be clearer if you renamed your probe.)
> 
> I'm worried about overhead here. If you have to do that string
> comparison in every function, it seems like that would only work for a
> small tapset. If you've got a large tapset (or a tapset function that
> calls another tapset function in a loop), that overhead is going to add
> up. One way to lower to overhead would be to have a set of public
> functions that do the pp() check, which are basically wrappers around
> private functions that don't.
> 
> Are there other ways to lower the overhead? Could each probe set a
> global indexed by tid() to some value? (Or by that point would the
> string comparison you are using be about the same?)

A global integer instead of the string comparison could be set if you
are worried about the overhead. In the example above, tid() could be
saved in the probe alias body as a private global which would be sufficient
for identifying the desired function.  

> 
> --
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)
>