Date: Fri, 30 Jan 2015 10:36:19 +0000 From: "George Neville-Neil" <gnn@neville-neil.com> To: "Mark Johnston" <markj@FreeBSD.org> Cc: freebsd-dtrace@freebsd.org Subject: Re: removing USDT's libelf dependency Message-ID: <A8A5A535-D8E4-4ADE-8962-810B48261627@neville-neil.com> In-Reply-To: <20150130061355.GA14037@raichu> References: <20150130061355.GA14037@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8A5A535-D8E4-4ADE-8962-810B48261627>