removing USDT's libelf dependency

Ed Maste emaste at freebsd.org
Fri Jan 30 15:15:31 UTC 2015


On 30 January 2015 at 01:13, Mark Johnston <markj at freebsd.org> wrote:
>
> 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.

I'm not worried about issues with lld here - we can make it meet our
requirements. I am a little worried that there will be code floating
around that does strcmp(foo, ".SUNW_dof") though. A quick search
turned up some examples.  Most are copies of drti.c but I did find one
case in some markjdb Github repo :-)  Even if we don't end up changing
.SUNW_dof I think we should convert these cases to use the section
type instead of name.

We could give GNU ld 2.17.50 and lld knowledge of .SUNW_dof and
__SUNW_dof. This looks like it would be straightforward, but at the
cost of carrying around different FreeBSD-specific changes.

I think our best approach will be to find an approach that upstream
linker projects (GNU ld, gold, lld) are willing to support. But, until
or unless that happens I'd much rather we switch to SUNW_dof than
require linking against libelf.


More information about the freebsd-dtrace mailing list