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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace To unsubscribe, send any mail to "[email protected]"
