[llvm-dev] [lld] avoid emitting PLT entries for ifuncs

[Mark Johnston via llvm-dev]

On Thu, Aug 23, 2018 at 03:14:33PM +0900, Rui Ueyama wrote:
> In the context of support not only IFunc but DTrace, what kind of features
> do you want to add to lld, if you have a chance to implement it in the
> linker instead of a post-processing tool? I wonder if we can solve both of
> your problems.

I will try to explain what dtrace -G does first.  It is required to
support USDT, which is a dtrace feature that allows one to define static
tracepoints in a usermode application.  In C, the tracepoints look like
ordinary function calls (with programmer-defined parameters); dtrace
allows one to "tap" those tracepoints by overwriting them with a
breakpoint at runtime.  At build time, dtrace -G processes each
relocatable object file, and outputs an object file which must be linked
into the final output.  When processing the input object files, dtrace
looks for relocations against undefined symbols prefixed by "__dtrace_";
each such relocation is a tracepoint.  It overwrites the corresponding
call with nops, changes the relocation type to R_[*]_NONE, and records
the tracepoint address, along with other information, in a metadata
section named ".SUNW_dof".  This metadata section is placed in the
output object file, which contains a constructor that registers the DOF
section with the kernel during application startup.

To me this functionality seems closely related to the -zifunc-noplt
option even if the details differ.  In both cases we really just
want the static linker to leave a certain set of relocations alone, and
pass them through to the output file.  (In the case of dtrace, the
symbols referenced by the relocations are undefined, and in the case of
ifunc-noplt the symbols are defined.)  A third item on my wishlist is
a way to dynamically disable retpolines during boot; having the set of
retpoline thunk calls available as relocations would make that
achievable in principle.

I haven't thought very much about how to extend lld to support my dtrace
use-case - the ifunc problem is simpler and more self-contained so I
started there.