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 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131020133119.gb2...@toonder.wildebeest.org
