dtrace-generated and direct includes are not very compatible

[Craig Ringer <craig@2ndquadrant.com>]

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