Re: Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev
On Sun, Oct 20, 2013 at 01:07:33AM +0200, Robert Millan wrote:
> > 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?
It is a two way street. Or multi-way, it isn't just systemtap, gdb and
perf for example also take advantage of them. For java the SDT markers
were already there and all it took was build them with the right sys/sdt.h
installed and now you can use them with any tool (stap, gdb, perf) that
can read the right ELF section magic. For qemu it was the other way around,
they were specifically added for stap, but you can also use them from gdb
or perf. And when rebuild on Solaris with their sys/sdt.h they are also
usable by dtrace. See e.g. https://www.berrange.com/posts/2011/11/30/watching-the-libvirt-rpc-protocol-using-systemtap/
> > 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?
sys/sdt.h and compiler as producer of the SDT ELF section, gdb/binutils,
perf and stap as consumers at a minimum.
> 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?
It really isn't just systemtap, that is just one of the programs that
can consume the SDT markers produced in the special ELF notes. gdb and
perf at least can also use them for debugging and profiling. I don't know
about dtrace, but on a system with a GNU toolchain I assume
it can be made to work with the SDT ELF section too. It is all documented
https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
For systemtap that is just one of the probe sources you can use. There
are others inside the kernel, timers, syscalls, etc. I assume dtrace
also has various sources from which it can generate traces?
> 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?
Yes, systemtap can also use both kernel and userland probes.
perf also can profile both kernel and user space.
gdb only does user space, but there is a special linux kernel kgdb.
> > 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?
I don't know what your sys/sdt.h produces when it sees a DTRACE_PROBE macro.
I don't believe gdb knows how to interpret those. But it does know how
to interpret the SDT markers produced by the sys/sdt.h header from
std-dev. You can set (conditional) breakpoints on them, etc. And it even
knows about some special ones in glibc and libgcc that help gdb with
exceptions or shared library loading issues. You can think of DTRACE_PROBE
macros as special places to set a breakpoint on. gdb uses those in one
specific way, systemtap uses it for tracing, perf uses them for profiling,
etc.
> 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.
Systemtap doesn't work on any system/kernel that has a "dtrace ABI" as
far as I know. Is there a discription of this ABI? I guess if there is
a specification of how SDT probes are embedded in could be made to
also interpret them (given we find some volunteers).
BTW. This isn't a new thing on GNU/Linux. This has been integrated in
various distributions for years. That is why the request came to make
sdt-dev an integral part (arch:all) for Debian too. Then tools like gdb
can rely on it and do several things currently not possible or less
efficiently.
> > 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.
It would be good to know if it actually works and has any programs/users.
I was only asking because if user space dtrace does work then it might
be a good idea to make it understand the sys/sdt.h variant ELF notes.
But if there are no programs/users for it currently then it would be
easier to resolve the conflict between the packages. I don't know enough
about Debian kfreebsd to tell what (user space) solution is best.
Cheers,
Mark
Reply to: