removing USDT's libelf dependency

George Neville-Neil gnn at neville-neil.com
Fri Jan 30 10:36:39 UTC 2015


On 30 Jan 2015, at 6:13, Mark Johnston wrote:

> 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?
>

Do it.  I can't see a problem thus far.

Best,
George


More information about the freebsd-dtrace mailing list