Re: new static user probe types

[Mark Wielaard <mjw@redhat.com>]

Hi Frank,

On Wed, 2009-07-22 at 10:39 -0400, Frank Ch. Eigler wrote:
> Or how about this.  We could expand STAP_PROBE(...) to
> 
>    { extern char stap_probe_NNNN_enabled_p;
>      if (unlikely(stap_probe_NNN_enabled_p)) {
>         /* current inline-asm stuff, but adding
>            &enabled_p to the descriptor struct. */
>      }
>    }
> 
> Since this FOO_enabled_p variable would be initialized to 0, this
> would allow bypass of all the instrumentation inline-asm in the
> instrumentation-off case.  To turn on the instrumentation, the
> systemtap runtime would poke at the target process's memory to
> (atomically) increment that flag byte, and vice versa.  (Increment
> instead of set, in case multiple systemtap sessions are targeting the
> same process.)
> 
> The inline-asm inside could be the fastest enabled variant, probably
> the kprobe-based one.  (This would make user-space sdt.h usable
> without utrace & uprobes.)

O, I like it. It is probably not as zero-overhead as the "pure nop"
approach, but it would be easy (well, relatively, the sdt macros
assembly stuff is slightly hard, at least for me) to implement (easier
than extending the ubp stuff at least). Certainly warrants a try and
benchmark. Making this only need kprobes is also appealing (even though
I really wish to see utrace and uprobes move forward and into the
mainline kernel).

BTW. For storing changeable variables the .probes section should become
alloc, rw now always (it currently is only for relocatable objects). How
to keep the section/parsing compatible with older versions already
compiled into programs is also left as an exercise to the reader...

Cheers,

Mark