Re: Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev
On Sat, 2013-10-19 at 02:21 +0200, Robert Millan wrote:
> On 18/10/2013 22:18, Timo Juhani Lindfors wrote:
> > It is certainly meant to be usable for software that wants to use SDT
> > probes (like glibc in this example) and software that wants to
> > read/inspect the SDT probes embedded in other software (like gdb in this
> > example).
>
> So the SDT probes provided by systemtap-sdt-dev are not kernel-specific?
No, they are not. Just like I suspect the variant in the
kfreebsd-kernel-headers isn't. They are for programs that want to define
Staticly Defined Tracepoints for user applications.
> It seems the namespace collision is not by chance. The <sys/sdt.h> in
> systemtap is probably inspired by a DTrace version of <sys/sdt.h>, which
> is what FreeBSD kernel headers seem to be providing.
Indeed. They were created so that for programs that include sys/sdt.h
and define DTRACE_PROBE macros everything just works. Same include, same
macros, just a recompile against the gnu toolchain. Then all the SDT
tracepoints in the program are available to all the tools that can read
them.
> How compatible are the different implementations?
They are meant to be source compatible so that if programs use
DTRACE_PROBE macros they get build with SDT probes that systemtap, perf,
gdb, etc. can use to introspect the program. High-level overview:
http://tromey.com/blog/?p=687
Implementation bits that describe the ELF sections created:
https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
> If they're meant to be
> bit-by-bit compatible, then it should be possible for systemtap-sdt-dev
> to just skip this file on kfreebsd-* so that applications will use the
> FreeBSD version. Do you think this could work?
I suspect, but haven't checked, that the sys/sdt.h variant in
kfreebsd-kernel-headers is also source compatible, but might produce
different ELF section bits, so that tools like gdb won't be able to read
the SDT probes when that version is used. So, it should be possible to
install either of the variants to build depending on the user space
tools one wants/needs. The case given in the bug is glibc and gdb which
I believe are both used on the Debian kfreebsd.
But the real goal is just to have the sdt-dev package be arch:any. They
don't have to be used on the Debian kfreebsd arch if really not needed,
as long as they don't conflict in such a way that that would prevent the
package being arch:any. Which is why I suggested extracting your
sys/sdt.h variant also in a separate package (not being build
essential), so that either can be installed (even if they would conflict
with each other). But note that I am not a Debian packager, so I might
miss some other more obvious solution.
Reply to: