search for: noplt

...n references a symbol of type GNU_IFUNC, then during boot we can resolve each call site and apply the relocation before mapping the kernel text read-only. Then, ifunc calls have the same overhead as regular function calls. To implement this optimization, I wrote an lld patch to add "-z ifunc-noplt". When this option is specified, lld does not create PLT entries for ifuncs and instead passes the existing PC-relative relocation through to the output file. The patch is below; I tested it with lld 7.0 and the patch applied without modifications to the sources in trunk. I'm wondering...

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. On Thu, Aug 23, 2018 at 1:33 AM Mark Johnston <markj at freebsd.org> wrote: > On Wed, Aug 22, 2018 at 10:11:00AM -0400, Ed Maste wrote: > > On 22

...sembly refers to a > function whose address can be insignificant. The assembler produces an > R_386_PLT32/R_X86_64_PLT32/R_AARCH64_PLT32 relocation which will be > resolved by the linker to either: > > * the definition (non-preemptible (logical AND (non-ifunc or ld.lld -z ifunc- > noplt is specified))) > * a PLT entry (other cases) > > The address can be insignificant: ultimately the program will call the > function. There is no difference if the program calls the function > directly or calls through one PLT entry in any module (executable or a > shared object)....

I do have concerns about the amount of object level modeling that we want to do in the IR though. While it isn't the highest level IR we've managed to mostly avoid these kinds of features/complications in the past. I'm definitely interested in hearing some alternate implementations here and there rather than a full set of constants for relocations. Keeping the IR abstract enough over