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

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Sun Aug 26 20:50:10 PDT 2018


Thank you very much for your explanation. That's very helpful.

It looks like even though DTrace and what you are trying to do with your
patch are conceptually similar, they are quite different in details, so I
can't think of a feature that can be used for both without depending on
other post-processing tools. Maybe it is better to create each feature
directly instead of creating something too generic.

I think  my concern about this patch is the cost of maintenance. The
feature will have a very small number of users (perhaps only FreeBSD), so
the cost of maintenance is relatively high even thought the feature is
tiny. I think I'm fine to accept this patch if you explicitly mark this as
an experimental feature that might be removed in a feature release of lld
if we find a better solution.

On Sat, Aug 25, 2018 at 5:05 AM Mark Johnston <markj at freebsd.org> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180827/cfe63f91/attachment.html>


More information about the llvm-dev mailing list