Hi - > [...] > > If we use systemtap-sdt-dev's sys/sdt.h, do we at least get something > > that might be functional? > > I guess we will get better integration with GDB at the expense of no > integration with the kernel. > > Hopefully Mark can elaborate on this.
In the normal Linux case, it's particularly attractive because glibc (ld.so) and gdb have a little romance going, using sys/sdt.h as a love-note messenger. One offspring of this capability is much-accelerated handling of target shared libraries in gdb. Other cuddlesome cousins would be gdb breakpoint-attachment to other apps compiled against systemtap-style sdt.h. Some of these may enchant debian/kfreebsd too. Perhaps the way to resolve this confusing concubinage would be to have each sdt.h-instrumented app choose, via the equivalent of RPM BuildRequire:, between the competing sys/sdt.h suitors at build time. Tragically, she can choose only one. (In principle, an ELF executable could include both types of instrumentation, so technological trigamy may become possible in the future.) For run-time dependencies/installation, the CDDL dtrace would be fine. The systemtap sys/sdt.h code will have left his scratch in the binaries for gdb to enjoy. HTH, till death do us 'part, amen. - FChE -- 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/20131020002350.gb29...@redhat.com
