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

[Mark Johnston via llvm-dev]

On Wed, Aug 22, 2018 at 10:11:00AM -0400, Ed Maste wrote:
> On 22 August 2018 at 04:27, Rui Ueyama via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > However, if you pass the -emit-relocs option to the linker, lld keeps all
> > relocations that have already been resolved in an output executable. By
> > analyzing a relocation table in a resulting executable, you could find all
> > locations where the ifunc PLT is called. Then, you can construct a new table
> > for your linker, embed it to the executable using objcopy or something like
> > that, and then let the kernel loader interpret it.
> >
> > Have you considered that?
> 
> I've thought about alternative ways to achieve the same thing,
> including something like the above. My concern with that approach is
> that it's rather cumbersome and can be error-prone, and introduces a
> requirement for awkward multi-stage linking.

A couple of years ago I did something very much like this to experiment
with hot-patched static DTrace probes in the kernel.  My conclusion at
the time was that even this kind of functionality (selective filtering
of relocations as a post-processing step) was quite awkward and is much
more easily implemented in the static linker.[*]  In this case, we need to
modify the loadable segment descriptions, and we need to do some
unwinding of the static linker's work when processing non-RELA
relocations in the kernel.  It is all doable, but requires a significant
amount of both userland and kernel code and a custom,
FreeBSD-kernel-specific post-link step.

[*] dtrace -G basically does this already.  See dt_link.c in libdtrace:
it's 2000 LOC of complicated ELF handling, and it's required numerous
tweaks over the years to deal with changing behavioural quirks of GNU
ld and lld.  r313262 is an example of this:
https://svnweb.freebsd.org/changeset/base/313262
The integration of dtrace(1) into the build systems of projects that
wish to provide static probes is painful and often creates race
conditions with incremental rebuilds.  Rafael and I discussed this
several times and his general sentiment was that the functionality
provided by dtrace -G can be implemented much more sanely in lld.

> On 22 August 2018 at 09:20, Joerg Sonnenberger via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > On the linker side, it is a custom hack for
> > something that is generally considered very bad nowadays: text
> > relocations.
> 
> True, although the argument against .text relocations doesn't hold for
> our kernel use case.

Moreover, while being a hack, it is IMHO simply the right place to
implement this logic from an architectural standpoint.  The static
linker is pessimizing ifunc calls in a freestanding environment and it
has all the information required to avoid doing this, and in a robust
manner.  The small size of the required lld patch supports this view.
Addressing the problem any other way involves adding much larger and
more fragile hacks elsewhere.