Date: Thu, 29 Jan 2015 22:13:55 -0800 From: Mark Johnston <markj@FreeBSD.org> To: freebsd-dtrace@freebsd.org Subject: removing USDT's libelf dependency Message-ID: <20150130061355.GA14037@raichu>
next in thread | raw e-mail | index | archive | help
Hello, At the moment, any FreeBSD program containing USDT probes needs to be linked with libelf. This is so that drti.o can find the address of the DOF section within the executable or library. With this, it can extract the DOF and load it into the kernel prior to beginning execution. This requirement is an annoyance since it's specific to FreeBSD and many upstream projects which support DTrace aren't aware of it, so some patching is necessary to get their probes working on FreeBSD. It also increases the startup cost of programs containing USDT probes, which can be significant for e.g. sh(1) or libc/libthr (plockstat). Solaris exploits a feature of its linker to solve this problem - the dtrace -G step emits an object file containing a symbol called __SUNW_dof; the linker knows to fill in the value of this symbol with the address of the DOF section, so drti.o begins execution with the DOF section already available. It turns out that GNU ld implements a similar feature, albeit in a more restrictive manner: a symbol named __start_<id> will have its value filled in with the address of the section named <id>. The catch is that <id> has to be a valid C identifier, and the DOF section is conventionally named ".SUNW_dof", which of course doesn't quite work. I propose using "SUNW_dof" instead so that we can make use of this linker feature and eliminate the libelf dependency. DOF sections have their own ELF section type (SHT_SUNW_dof), so anything that might want to find a DOF section should already be searching for that rather than the conventional name. Depending on this linker feature is also arguably a portability concern given that lld is on the horizon, but we depend on it already anyway - this feature is used in FreeBSD's linker set implementation (which in turn is used by our SDT code :). So I don't think this would introduce a new problem. Any thoughts? Thanks, -Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150130061355.GA14037>