dtrace-generated and direct includes are not very compatible

dtrace-generated and direct includes are not very compatible

[Craig Ringer]

Hi all

During some recent work I noticed that if you #include a probes.h generated
by stap's dtrace tool from a probes.d, it will enable semaphores for ALL
probes, irrespective of how they are defined.

You cannot define your own separate DTRACE_PROBE()s or STAP_PROBE()s
directly elsewhere in the code if the probes.h is included first, as
systemtap's macros will expect there to be semaphore symbols for them.

There are no macros exposed to generate the semaphore symbols dynamically
in the same manner as the probes.

You can disable semaphore use entirely by including <sys/sdt.h> before your
"probes.h" - at the cost of disabling semaphores for the probes themselves
too.

There's no macro you can define before including <sys/std.h> to explicitly
disable semaphores; only one defined by probes.h that enables them. And
it's only effective at include time, taking effect for all probe macros
used after the header is included.

That's probably not ideal. So I suggest the following changes, which I can
follow with a patch if you agree they make sense:

* Define new variants of STAP_PROBE() etc like STAP_PROBE_WITH_SEMAPHORE()
. Use these in the generated probes.h instead of defining a macro to enable
semaphores globally

* Replace the duplicated block of code for each probe in the generated
probes.h with just a pair of macros defined in <sys/std.h> like

    STAP_PROBE_DECLARE_SEMAPHORE(providername, foo);

    #define PROBE_PROVIDERNAME_FOO()
STAP_PROBE_WITH_SEMAPHORE(providername,foo)

* Also expose a STAP_PROBE_DEFINE_SEMAPHORE(providername, foo) in
<sys/sdt.h> and generate a .c file alongside the .h file. Applications may
choose to compile the generated .c file containing these macros instead of
linking the dtrace-script-generated .o file directly.

* Don't define _SDT_HAS_SEMAPHORES in probes.h anymore. Continue to respect
it with the old behaviour in <sys/sdt.h> if it's defined, by making each
STAP_PROBE() etc map to STAP_PROBE_WITH_SEMAPHORE() when it's defined.

This gives apps the flexibility to define their own probes with semaphores
dynamically from within their own code and macros. It also allows apps that
want to dynamically define probes _without_ such semaphores if they want,
without upsetting dtrace-style probe generation.

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise

Re: dtrace-generated and direct includes are not very compatible

[Frank Ch. Eigler]

Hi, Craig -

> During some recent work I noticed that if you #include a probes.h generated
> by stap's dtrace tool from a probes.d, it will enable semaphores for ALL
> probes, irrespective of how they are defined.

Yup.

> You cannot define your own separate DTRACE_PROBE()s or STAP_PROBE()s
> directly elsewhere in the code if the probes.h is included first, as
> systemtap's macros will expect there to be semaphore symbols for them.

Yup.

> There are no macros exposed to generate the semaphore symbols dynamically
> in the same manner as the probes.

And Yup.

All this is accidental.


> That's probably not ideal. So I suggest the following changes, which I can
> follow with a patch if you agree they make sense:
>
> * Define new variants of STAP_PROBE() etc like STAP_PROBE_WITH_SEMAPHORE()
> . Use these in the generated probes.h instead of defining a macro to enable
> semaphores globally

OK.

> * Replace the duplicated block of code for each probe in the generated
> probes.h with just a pair of macros defined in <sys/std.h> like
>
>     STAP_PROBE_DECLARE_SEMAPHORE(providername, foo);
>
>     #define PROBE_PROVIDERNAME_FOO()
> STAP_PROBE_WITH_SEMAPHORE(providername,foo)

Whatever makes most sense here.  Varargs and conditional macros make it
tricky.  Well motivated/explained code duplication is fine.


> * Also expose a STAP_PROBE_DEFINE_SEMAPHORE(providername, foo) in
> <sys/sdt.h> and generate a .c file alongside the .h file. Applications may
> choose to compile the generated .c file containing these macros instead of
> linking the dtrace-script-generated .o file directly.

I don't think we really need a .c file; a .h that contains the extern
semaphore shorts would sit just fine in the .h.


> * Don't define _SDT_HAS_SEMAPHORES in probes.h anymore. Continue to respect
> it with the old behaviour in <sys/sdt.h> if it's defined, by making each
> STAP_PROBE() etc map to STAP_PROBE_WITH_SEMAPHORE() when it's defined.

OK.

> This gives apps the flexibility to define their own probes with semaphores
> dynamically from within their own code and macros. It also allows apps that
> want to dynamically define probes _without_ such semaphores if they want,
> without upsetting dtrace-style probe generation.

OK.

- FChE