<div dir="ltr"><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 23, 2018 at 1:33 AM Mark Johnston <<a href="mailto:markj@freebsd.org">markj@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Aug 22, 2018 at 10:11:00AM -0400, Ed Maste wrote:<br>
> On 22 August 2018 at 04:27, Rui Ueyama via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > However, if you pass the -emit-relocs option to the linker, lld keeps all<br>
> > relocations that have already been resolved in an output executable. By<br>
> > analyzing a relocation table in a resulting executable, you could find all<br>
> > locations where the ifunc PLT is called. Then, you can construct a new table<br>
> > for your linker, embed it to the executable using objcopy or something like<br>
> > that, and then let the kernel loader interpret it.<br>
> ><br>
> > Have you considered that?<br>
> <br>
> I've thought about alternative ways to achieve the same thing,<br>
> including something like the above. My concern with that approach is<br>
> that it's rather cumbersome and can be error-prone, and introduces a<br>
> requirement for awkward multi-stage linking.<br>
<br>
A couple of years ago I did something very much like this to experiment<br>
with hot-patched static DTrace probes in the kernel.  My conclusion at<br>
the time was that even this kind of functionality (selective filtering<br>
of relocations as a post-processing step) was quite awkward and is much<br>
more easily implemented in the static linker.[*]  In this case, we need to<br>
modify the loadable segment descriptions, and we need to do some<br>
unwinding of the static linker's work when processing non-RELA<br>
relocations in the kernel.  It is all doable, but requires a significant<br>
amount of both userland and kernel code and a custom,<br>
FreeBSD-kernel-specific post-link step.<br>
<br>
[*] dtrace -G basically does this already.  See dt_link.c in libdtrace:<br>
it's 2000 LOC of complicated ELF handling, and it's required numerous<br>
tweaks over the years to deal with changing behavioural quirks of GNU<br>
ld and lld.  r313262 is an example of this:<br>
<a href="https://svnweb.freebsd.org/changeset/base/313262" rel="noreferrer" target="_blank">https://svnweb.freebsd.org/changeset/base/313262</a><br>
The integration of dtrace(1) into the build systems of projects that<br>
wish to provide static probes is painful and often creates race<br>
conditions with incremental rebuilds.  Rafael and I discussed this<br>
several times and his general sentiment was that the functionality<br>
provided by dtrace -G can be implemented much more sanely in lld.<br>
<br>
> On 22 August 2018 at 09:20, Joerg Sonnenberger via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > On the linker side, it is a custom hack for<br>
> > something that is generally considered very bad nowadays: text<br>
> > relocations.<br>
> <br>
> True, although the argument against .text relocations doesn't hold for<br>
> our kernel use case.<br>
<br>
Moreover, while being a hack, it is IMHO simply the right place to<br>
implement this logic from an architectural standpoint.  The static<br>
linker is pessimizing ifunc calls in a freestanding environment and it<br>
has all the information required to avoid doing this, and in a robust<br>
manner.  The small size of the required lld patch supports this view.<br>
Addressing the problem any other way involves adding much larger and<br>
more fragile hacks elsewhere.<br>
</blockquote></div>