This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: dtrace-generated and direct includes are not very compatible
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