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

[Mark Johnston via llvm-dev]

On Mon, Aug 27, 2018 at 12:50:10PM +0900, Rui Ueyama wrote:
> 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 do agree at this point that these features are probably too different
to be implemented in a generic way.  They would all benefit from some
support in the static linker even if some amount of post-processing is
necessary in the end.  I'm not sure what kind of design Rafael had in
mind for dtrace, if any.

> 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.

Thanks.  I'll work on writing some tests and polishing the existing
patch.

> 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.
> >