Re: [ltt-dev] SystemTAP support in tracepoints

[Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>]

* Mark Wielaard (mjw@redhat.com) wrote:
> On Wed, 2011-04-13 at 11:38 -0400, Mathieu Desnoyers wrote:
> > * Mark Wielaard (mjw@redhat.com) wrote:
> > > I have just been using the following configure check:
> > > 
> > > AC_CHECK_HEADER([sys/sdt.h], [SDT_H_FOUND='yes'],
> > >                 [SDT_H_FOUND='no';
> > >                    AC_MSG_ERROR([systemtap support needs sys/sdt.h header])])
> > > 
> > > Which you can adapt to your needs with/without error message, including
> > > an test to see if it fully works for your environment.
> > 
> > Thanks for the hint, but adding this test in the UST build system don't
> > really make sense, because both systemtap and UST don't have dependency
> > on each other, and thus the build order between the two packages is not
> > fixed. So the detection should be done when the UST header is being
> > included into an application rather than at UST configuration time. And
> > I don't want to require all applications that want to use tracepoint to
> > use autoconf neither.
> 
> Sure autoconf is optional. But if you want UST tracepoints to be
> recognized by other consumers that use SDT probe points, then just
> depending on the availability of sys/sdt.h in UST seems to make the most
> sense. Note that sys/sdt.h is kind of independent from systemtap proper.
> It can be installed independently from the systemtap stap translator or
> runtime. And it is only a build dependency, not a runtime dependency.
> All consumers just parse the notes section to get the addresses to place
> their probes and extract the arguments. There is even a binutils bfd
> extractor now.

So we seem to have two choices here: either add a dependency on the
package providing sdt.h in UST, or copy sdt.h into UST (it's public
domain, so the licensing permits it).

For the package dependency: I'd need to know:

1 - which package provide sdt.h.
2 - which distributions provide it.
3 - what the dependencies of the package are.
4 - which architectures are supported by this package.

we must keep in mind that UST targets many distributions and many
architectures.

For the sdt.h copy: we could certainly ship it into UST too. It might be
much, much easier. I would put it in ust/sdt.h so we don't overwrite the
SystemTAP header when we install it.  We'd have to be careful about
changes to this header though, because we can end up with two entirely
different versions. The #ifndef _SYS_SDT_H would take care of handling
multiple inclusion of the ust and systemtap sdt.h header incarnations.

One way to handle this versioning problem would be to define a header
"version" at the beginning of sdt.h in both SystemTAP and UST
incarnations:

#define _THIS_SDT_H_VERSION  3
#if (!defined(_SDT_H_VERSION) || _SDT_H_VERSION < _THIS_SDT_H_VERSION)

either

#undef all sdt.h macros
/* rest of the sdt.h header */

or

/* this scheme would require that we only append to the SDT macros,
 * never change the macros per se */
#ifndef each macro name
#define macro
#endif

#endif
#undef _SDT_H_VERSION
#define _SDT_H_VERSION  _THIS_SDT_H_VERSION
#undef _THIS_SDT_H_VERSION

Thoughts ?

Thanks,

Mathieu

> 
> Cheers,
> 
> Mark
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com