This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]