Re: Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev
On 19/10/2013 18:06, Mark Wielaard wrote:
> On Sat, Oct 19, 2013 at 05:00:48PM +0200, Robert Millan wrote:
>> If you want to avoid modifying programs that #include <sys/sdt.h>, why
>> not just install it in /usr/include/systemtap/sys/sdt.h ? Then you can
>> build them with -I/usr/include/systemtap so that your version takes
>> preference.
>
> But then programs that expect the header to be in the default place
> wouldn't build. The whole idea is that programs that use sys/sdt.h
> (and optionally the dtrace script) to use DTRACE_PROBE macros to
> define SDT probe points get them without having to change anything
> to their build system. They just detect in configure the sys/sdt.h
> is available (possibly checking for the dtrace script and whether
> the compiler is capable of building with DTRACE_PROBE macros).
> That is how for example qemu, java hotspot or libreoffice do it.
So the probes you're referring to were added for DTrace, and SystemTap
takes advantage of them by providing a DTrace-compatible API. Is this
correct?
> The default sys/sdt.h header should match the toolchain and user space
> you are using.
Toolchain and user space are very generic terms. Which components do you
have in mind?
> It looks to me that for Debian that should be the one
> from sdt-dev, not the fbsd specific kernel header.
If I understand correctly, we can't support both SystemTap and DTrace at
the same time, because SystemTap only aims for API compatibility, not
ABI compatibility, so we have to choose one to link everything against?
SystemTap is a Linux tool. What is the advantage of using it on
kFreeBSD, in comparison with DTrace?
As DTrace is fully integrated in FreeBSD upstream, theoretically we
could use it to debug both kernel and userland. Is it possible to do the
same with SystemTap?
> But if you think that on kfreebsd programs should be build against
> a different sys/sdt.h that is fine too (but then programs like gdb
> will not work with the SDT probes in programs and libraries or will
> be less efficient when handling things in glibc and libgcc).
So you're saying that GDB has features which work with SystemTap, but
not with DTrace?
> All that
> is really needed is that the sdt-dev package can be made arch:all.
> Whether or not it is installed by default and/or whether it provides
> the default sys/sdt.h alternative header is secondary. I don't know
> enough about Debian packaging to suggest the right course of action
> of making the package arch:all. But that is what Bug#726248 is really
> about as I understood it. systemtap-sdt-dev: should be "Arch: all"
> so gcc and libc can B-D on it.
Okay, now I see that we can't really provide both headers, even if
they're in separate packages, as userland will expect consistent
behaviour when including <sys/sdt.h>, whichever that may be.
> How did you resolve the conflicts between kfreebsd-kernel-headers
> and glibc-headers? Maybe the same solution can be used here?
This would only work if SystemTap could be adjusted to use the same ABI
as DTrace. That would be the best solution IMHO. But it might not be
feasible.
> Does any user space program Debian actually use the kfreebsd
> sys/sdt.h variant?
Well, I guess that anything that has support for DTRACE_PROBE is already
using it. Haven't checked if this actually works though.
--
Robert Millan
Reply to: