<div dir="ltr">Thank you very much for your explanation. That's very helpful.<div><br></div><div>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.</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 25, 2018 at 5:05 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 Thu, Aug 23, 2018 at 03:14:33PM +0900, Rui Ueyama wrote:<br>
> In the context of support not only IFunc but DTrace, what kind of features<br>
> do you want to add to lld, if you have a chance to implement it in the<br>
> linker instead of a post-processing tool? I wonder if we can solve both of<br>
> your problems.<br>
<br>
I will try to explain what dtrace -G does first.  It is required to<br>
support USDT, which is a dtrace feature that allows one to define static<br>
tracepoints in a usermode application.  In C, the tracepoints look like<br>
ordinary function calls (with programmer-defined parameters); dtrace<br>
allows one to "tap" those tracepoints by overwriting them with a<br>
breakpoint at runtime.  At build time, dtrace -G processes each<br>
relocatable object file, and outputs an object file which must be linked<br>
into the final output.  When processing the input object files, dtrace<br>
looks for relocations against undefined symbols prefixed by "__dtrace_";<br>
each such relocation is a tracepoint.  It overwrites the corresponding<br>
call with nops, changes the relocation type to R_[*]_NONE, and records<br>
the tracepoint address, along with other information, in a metadata<br>
section named ".SUNW_dof".  This metadata section is placed in the<br>
output object file, which contains a constructor that registers the DOF<br>
section with the kernel during application startup.<br>
<br>
To me this functionality seems closely related to the -zifunc-noplt<br>
option even if the details differ.  In both cases we really just<br>
want the static linker to leave a certain set of relocations alone, and<br>
pass them through to the output file.  (In the case of dtrace, the<br>
symbols referenced by the relocations are undefined, and in the case of<br>
ifunc-noplt the symbols are defined.)  A third item on my wishlist is<br>
a way to dynamically disable retpolines during boot; having the set of<br>
retpoline thunk calls available as relocations would make that<br>
achievable in principle.<br>
<br>
I haven't thought very much about how to extend lld to support my dtrace<br>
use-case - the ifunc problem is simpler and more self-contained so I<br>
started there.<br>
</blockquote></div>