[LLD][ELF] Add the -z ifunc-noplt option

[markj]

Summary

When the option is configured, ifunc calls do not go through the PLT;
rather, they appear as regular function calls with relocations
referencing the ifunc symbol, and the resolver is invoked when
applying the relocation. This is intended for use in freestanding
environments where text relocations are permissible and is incompatible
with the -z text option. The option is motivated by ifunc usage in the
FreeBSD kernel, where ifuncs are used to elide CPU feature flag bit
checks in hot paths. Instead of replacing the cost of a branch with that
of an indirect function call, the -z ifunc-noplt option is used to ensure
that ifunc calls carry no hidden overhead relative to normal function
calls.

Test Plan:
I added a couple of regression tests and tested the FreeBSD kernel
build using the latest lld sources.

To demonstrate the effects of the change, I used a micro-benchmark
which results in frequent invocations of a FreeBSD kernel ifunc. The
benchmark was run with and without IBRS enabled, and with and without
-zifunc-noplt configured. The observed speedup is small and consistent,
and is significantly larger with IBRS enabled:

https://people.freebsd.org/~markj/ifunc-noplt/noibrs.txt
https://people.freebsd.org/~markj/ifunc-noplt/ibrs.txt

[ruiu]

Generally looking good.

lld/ELF/Driver.cpp

891

According to the convention, this should be ZIfuncNoplt.

lld/docs/ld.lld.1

552–553

IIRC, text relocations are not preferred but actually permitted in most environment, no? I'd mention that this option is intended to be used for the kernel where an existence of text relocation doesn't matter but the cost of PLT matters.

[MaskRay]

Do you want to add a DT_TEXTREL tag?

// SyntheticSections.cpp
  if (!Config->ZText)
    addInt(DT_TEXTREL, 0);

[MaskRay]

lld/test/ELF/gnu-ifunc-noplt-i386.s

9

Where is the IRELATIVE relocation? And I don't think the ordering matters.

43

Not sure if you need bar2@plt zed2@plt. The normal PLT entries are checked by numerous tests.

lld/test/ELF/gnu-ifunc-noplt.s

9

Same question goes here.

[MaskRay]

lld/test/ELF/gnu-ifunc-noplt.s

38

You FreeBSD llvm-objdump is old XD

The misindentation made me unhappy so I fixed it in rL358405.

[emaste]

lld/docs/ld.lld.1

552–553

I think that's fair - by default the linker won't permit the creation of .text relocations but they are permitted by the runtime environment.

[markj]

Address feedback:

• Set DT_TEXTREL
• Rename the config flag to match Capitalization Conventions
• Clarify some text in the man page update
• Fix test comments and indentation

[markj]

lld/test/ELF/gnu-ifunc-noplt-i386.s

9

My mistake, sorry. I left a few TODO comments and forgot to fix them before creating the review. There should not be any IRELATIVE relocations.

43

I just reused them from gnu-ifunc-plt.s. If you prefer I can remove them, though I need to add -pie or so to ensure that lld doesn't try to resolve the relocations statically.

lld/test/ELF/gnu-ifunc-noplt.s

38

Not too old :)

> llvm-objdump --version
LLVM (http://llvm.org/):
  LLVM version 8.0.0

[ruiu]

LGTM

[MaskRay]

lld/test/ELF/gnu-ifunc-noplt.s

38

My change will be included by llvm 9.0.0 ;-) Since you've cloned the monorepo, you may run ninja -C your/build llvm-objdump and use that llvm-objdump to update the tests.

I still suggest fixing the misaligned instructions before you commit...

[MaskRay]

FreeBSD makes use of the option when linking x86 kernels, which now make heavy use of ifuncs in hot paths. Without the option, each ifunc results in the generation of a PLT entry, so calls needlessly incur the extra overhead of an indirect jump. With the option, ifunc calls have the same cost as ordinary function calls.

Oh I recall this one and find your efforts to push forward this.

I remember I asked if you got numbers of the improvement and you didn't have an answer then. I still hope you can share the benchmark to justify this is a useful feature. According to my understanding, -z ifunc-noplt will introduce many text relocations (a kind of dynamic relocations), that will slow down the dynamic loader. The overhead resolving the text relocation pays off after the function has been called a few number of times. Surely you have hot paths, but many others are cold. The problem of -z ifunc-noplt is that it is too large a hammer - it applies to the whole module.

If you extend the usage to userspace applications you may have to tune the runtime code of static linked programs.

If you want a fast memcpy, I wonder why you can't define a global function pointer: void (*fast_memcpy)(void*,const void*,size_t) __attribute__((visibility("hidden"))) = slow_memcpy; and initializes it to a fast implementation at runtime.

Compared with the usual ifunc: GOT+PLT, this approach is similar to -fno-plt. I'd like to know why you think it doesn't meet your needs and you really need -z ifunc-noplt.

[MaskRay]

There is another issue: this feature is arch-specific and probably only applies on x86:

// ELF/Relocations.cpp#L880
    } else if (RelType Rel = Target->getDynRel(Type)) {
      In.RelaDyn->addReloc(Rel, &Sec, Offset, &Sym, Addend, R_ADDEND, Type);

On non-x86, you probably can't find an appropriate dynamic relocation type that resolves your desired text relocations. This looks to me a really hacky feature (linker support + textrel special case + more dynamic relocation type handling) that is limited to x86. Its benefit is also unclear (I can't find benchmarks in several of your FreeBSD patches). On the other hand, the alternative (a global function pointer) seems equally good.

[markj]

In D61613#1494472, @MaskRay wrote:

FreeBSD makes use of the option when linking x86 kernels, which now make heavy use of ifuncs in hot paths. Without the option, each ifunc results in the generation of a PLT entry, so calls needlessly incur the extra overhead of an indirect jump. With the option, ifunc calls have the same cost as ordinary function calls.

Oh I recall this one and find your efforts to push forward this.

I remember I asked if you got numbers of the improvement and you didn't have an answer then. I still hope you can share the benchmark to justify this is a useful feature.

See below.

According to my understanding, -z ifunc-noplt will introduce many text relocations (a kind of dynamic relocations), that will slow down the dynamic loader. The overhead resolving the text relocation pays off after the function has been called a few number of times. Surely you have hot paths, but many others are cold. The problem of -z ifunc-noplt is that it is too large a hammer - it applies to the whole module.

In our use-case the relocations are applied at boot time. My kernel has 3815 text relocations, all for ifuncs, which take 418672 cycles to resolve as measured by rdtsc on a Xeon E5-2630v3. The overhead is negligible and I expect it will stay that way.

I agree that -zifunc-noplt is not suitable for userspace applications, which must decide between the overhead of PLT calls and text relocations. In the kernel or other freestanding environments, text relocations do not have the same downsides, so the tradeoff is different.

If you extend the usage to userspace applications you may have to tune the runtime code of static linked programs.

If you want a fast memcpy, I wonder why you can't define a global function pointer: void (*fast_memcpy)(void*,const void*,size_t) __attribute__((visibility("hidden"))) = slow_memcpy; and initializes it to a fast implementation at runtime.

This still requires an indirect branch and has the added disadvantage that control flow is directed by pointers residing in writable memory.

Compared with the usual ifunc: GOT+PLT, this approach is similar to -fno-plt. I'd like to know why you think it doesn't meet your needs and you really need -z ifunc-noplt.

A function pointer still has extra, unnecessary overhead. We use ifuncs as a micro-optimization to avoid having CPU feature bit tests in commonly used functions. For instance, our copyout() implementation contains special logic for processors supporting SMAP. The overhead of testing the CPU feature bit is not high, but it is measurable in micro-benchmarks, and the test consumes CPU resources (extra I-cache footprint, branch predictor cache, etc.) to compute a result that is known at boot-time. Over time, as vendors introduce new CPU features, our code accrues more and more of these tests. ifuncs are an attractive mitigation for this problem, but if they use the PLT than we are still sacrificing CPU resources needlessly: the PLT occupies space in the instruction cache and the indirect call targets occupy space in a cache. -zifunc-noplt completely removes these overheads. I understand that they are small, but they accumulate as the code base grows and introduce cognitive overhead as programmers must think about the hidden cost behind what looks like an ordinary C function call.

In D61613#1494486, @MaskRay wrote:

There is another issue: this feature is arch-specific and probably only applies on x86:

// ELF/Relocations.cpp#L880
    } else if (RelType Rel = Target->getDynRel(Type)) {
      In.RelaDyn->addReloc(Rel, &Sec, Offset, &Sym, Addend, R_ADDEND, Type);

On non-x86, you probably can't find an appropriate dynamic relocation type that resolves your desired text relocations. This looks to me a really hacky feature (linker support + textrel special case + more dynamic relocation type handling) that is limited to x86. Its benefit is also unclear (I can't find benchmarks in several of your FreeBSD patches). On the other hand, the alternative (a global function pointer) seems equally good.

I tested the feature on arm64 and it works there as well. You are right that it requires support for static relocations in the kernel linker, but I do not see this to be a problem. We already implement a small "static" linker in the kernel (sys/kern/link_elf_obj.c) to handle the fact that loadable kernel modules are relocatable .o files instead of shared libs on some platforms (and the reason for this is again to avoid the PLT). IMO it is just another hint that the feature is not suitable for vanilla userspace.

To be clear, I do agree that this is hacky. It can not be used unless the application has some control over how it is linked; I tried to indicate this in the man page description. But, the implementation is extremely simple, and I believe the goal is conceptually reasonable. In the future, if the feature becomes too much work to maintain, it can be removed without affecting application correctness. In the meantime I intend to be available to support the patch if needed and refine it if possible.

Regarding benchmarks, I do not believe the patch will have an impact on any interesting macro-benchmark and did not attempt to measure. For the micro-benchmark, I used a program whose loop copies data out of the kernel at a high rate. In particular, it calls the copyout() ifunc frequently. I retried the test with the latest LLD sources. The code, data and summaries are here: https://people.freebsd.org/~markj/ifunc/

I tested with and without IBRS enabled, mostly to demonstrate that the optimization has an impact on microarchitectural resource usage. In particular, with IBRS enabled the improvement from -zifunc-noplt is more pronounced. The summaries show system CPU time consumed by the test program. "Patched" means -zifunc-noplt is configured.

https://people.freebsd.org/~markj/ifunc/ibrs.txt
https://people.freebsd.org/~markj/ifunc/noibrs.txt

The improvement is small and consistent.

[MaskRay]

Thanks for your explanation. I wanted to make sure the caveats of -z ifunc-noplt have been considered, the alternatives are compared before you decide to push forward these efforts :)

Over time, as vendors introduce new CPU features, our code accrues more and more of these tests. ifuncs are an attractive mitigation for this problem,

I will be glad if this helps some code organization problems! I did worry -z ifunc-noplt was proposed as it was a "fancy" feature. I asked musl guys, their feeling: "it's even worse on linux where they do this kind of hack; then happily make 10 abstraction layers; i don't get where folks get the idea to pour effort into wacky, costly microoptimizations like this when they have HUGE high-level performance problems". But they may not be aware of the FreeBSD situation.

Since you've proved this has been well-considered, I shall not block you from moving forward :)

I tested the feature on arm64 and it works there as well.

We already implement a small "static" linker in the kernel (sys/kern/link_elf_obj.c) to handle the fact that loadable kernel modules are relocatable .o files instead of shared libs on some platforms (and the reason for this is again to avoid the PLT).

Happy to know this is not x86 only. This indeeds requires the dynamic loader support of some "static" relocation types.

In the description,

Test Plan: I added a couple of regression tests and tested the FreeBSD kernel build using the latest lld sources.

If there are useful links, you may change this part of the commit description to include them.

lld/test/ELF/gnu-ifunc-noplt-i386.s

3

The -pc-linux part in i686-pc-linux does not matter. You don't have to call it Linux. Something like -triple=i686-pc-freebsd13.0 should also work. There are a few other tests using the freebsd triple, not many currently, but I hope there will be more in the future for other OSes or os-neutral -triple=x86_64.

% rg -l freebsd | wc -l
49
% rg -l linux | wc -l  
1346

[MaskRay]

lld/ELF/SyntheticSections.cpp

1238 ↗

(On Diff #198523)

Oh, this should probably be restored.

In http://lists.llvm.org/pipermail/llvm-dev/2018-August/125490.html , I think your opinion was that -z text -z ifunc-noplt = error.

[ruiu]

Mark,

Thank you for the explanation. I tend to oppose to add micro-optimizations to the ABI, but I agree that this particular optimization seems reasonable. I can imagine that with this feature you can use ifuncs in the kernel more liberally, which would make more difference in some test case.

[markj]

Address review feedback:

• Prohibit the combination of -ztext and -zifunc-noplt, add a regression test.
• Use a non-Linux OS in the triple for ifunc-noplt tests.

[markj]

In D61613#1495998, @MaskRay wrote:

Thanks for your explanation. I wanted to make sure the caveats of -z ifunc-noplt have been considered, the alternatives are compared before you decide to push forward these efforts :)

Certainly, I should have provided more justification in the review description. I appreciate the skepticism. :)

Over time, as vendors introduce new CPU features, our code accrues more and more of these tests. ifuncs are an attractive mitigation for this problem,

I will be glad if this helps some code organization problems! I did worry -z ifunc-noplt was proposed as it was a "fancy" feature. I asked musl guys, their feeling: "it's even worse on linux where they do this kind of hack; then happily make 10 abstraction layers; i don't get where folks get the idea to pour effort into wacky, costly microoptimizations like this when they have HUGE high-level performance problems". But they may not be aware of the FreeBSD situation.

I tend to agree with this view. FreeBSD is certainly not optimized to the point where a change like this is crucial. My two counter-points here would be:

• the patch is very small, and
• the patch is an optional optimization, i.e., if you decide to remove it in the future, FreeBSD will not lose any functionality.

If either of these statements were false, I would be much more reticent about trying to push the change upstream.

[...]

In the description,

Test Plan: I added a couple of regression tests and tested the FreeBSD kernel build using the latest lld sources.

If there are useful links, you may change this part of the commit description to include them.

Thanks for the feedback. I will update the review description to provide a better commit message.

In D61613#1496271, @ruiu wrote:

Thank you for the explanation. I tend to oppose to add micro-optimizations to the ABI, but I agree that this particular optimization seems reasonable. I can imagine that with this feature you can use ifuncs in the kernel more liberally, which would make more difference in some test case.

Right, my concern is with ifunc usage over time. The kernel started using ifuncs late last year and now we are up to 51 ifuncs, and I'm sure the number will keep growing.

lld/ELF/SyntheticSections.cpp

1238 ↗

(On Diff #198523)

Ah, right, thank you. I added a check to readConfigs() instead and added a test to basic.s. Hopefully that's appropriate.

lld/test/ELF/gnu-ifunc-noplt.s

38

Ok, but I believe I fixed the misalignment before your last comment here? I can't see any others.

[ruiu]

lld/ELF/Driver.cpp

930

Can you move this to checkOptions?

931

remove "the"

[markj]

Address feedback:

• Move check to checkOptions().
• Remove "the".

[ruiu]

I don't have any further comments. Fangrui, are you OK with this change?

lld/ELF/Driver.cpp

312

Let's use the same wording as other error messages: "-z text and -z ifunc-noplt may not be used together"

[markj]

Address feedback:

• Use consistent wording in the error message.

[MaskRay]

LGTM

lld/test/ELF/gnu-ifunc-noplt.s

25

// DISASM-NEXT: 201000: c3 retq

I believe you are still using an older llvm-objdump
After rL358474, you shall see

0000000000001001 bar:
    1001: c3                            retq

0000000000001002 _start:
    1002: e8 29 00 00 00                callq   41 <foo@plt>                                                   
    1007: e8 34 00 00 00                callq   52 <bar@plt>
    100c: e8 3f 00 00 00                callq   63 <bar2@plt>
    1011: e8 4a 00 00 00                callq   74 <zed2@plt>

A better test should probably use llvm-objdump --no-show-raw-insn as the hex bytes here are not useful.

[MaskRay]

lld/test/ELF/gnu-ifunc-noplt.s

5

x86_64-unknown-freebsd and x86_64-pc-freebsd do the same thing but it might be worth keeping consistency in the same file :)

[markj]

Address feedback:

• Use --no-show-raw-insn.
• Use a consistent triple.

lld/test/ELF/gnu-ifunc-noplt.s

5

Sigh, thanks.

25

I see, sorry. I reformatted all of the output using an updated llvm-objdump and added --no-show-raw-insn.

[markj]

Remove a command line that snuck in by accident.

[MaskRay]

Talked with Mark in an IRC channel and will commit on behalf of him :)

lld/ELF/Config.h

struct Configuration {
   bool WarnMissingEntry;
   bool WarnSymbolOrdering;
   bool WriteAddends;
   bool ZCombreloc;
   bool ZCopyreloc;
   bool ZExecstack;
   bool ZGlobal;
   bool ZHazardplt;
+  bool ZIfuncnoplt;
   bool ZInitfirst;
   bool ZInterpose;
   bool ZKeepTextSectionPrefix;
   bool ZNodefaultlib;
   bool ZNodelete;
   bool ZNodlopen;
   bool ZNow;
   bool ZOrigin;

lld/ELF/Driver.cpp

static void checkOptions() {
 
   if (!Config->Shared && !Config->AuxiliaryList.empty())
     error("-f may not be used without -shared");
 
   if (!Config->Relocatable && !Config->DefineCommon)
     error("-no-define-common not supported in non relocatable output");
 
   if (Config->Relocatable) {
     if (Config->Shared)
       error("-r and -shared may not be used together");
     if (Config->GcSections)
       error("-r and --gc-sections may not be used together");
     if (Config->GdbIndex)
       error("-r and --gdb-index may not be used together");
     if (Config->ICF != ICFLevel::None)
       error("-r and --icf may not be used together");
     if (Config->Pie)
if (K2 == Arg->getValue())
       return false;
   }
   return Default;
 }
 
 static bool isKnownZFlag(StringRef S) {
   return S == "combreloc" || S == "copyreloc" || S == "defs" ||
          S == "execstack" || S == "global" || S == "hazardplt" ||
-         S == "initfirst" || S == "interpose" ||
+         S == "ifunc-noplt" || S == "initfirst" || S == "interpose" ||
          S == "keep-text-section-prefix" || S == "lazy" || S == "muldefs" ||
          S == "nocombreloc" || S == "nocopyreloc" || S == "nodefaultlib" ||
          S == "nodelete" || S == "nodlopen" || S == "noexecstack" ||
          S == "nokeep-text-section-prefix" || S == "norelro" || S == "notext" ||
          S == "now" || S == "origin" || S == "relro" || S == "retpolineplt" ||
          S == "rodynamic" || S == "text" || S == "wxneeded" ||
          S.startswith("max-page-size=") || S.startswith("stack-size=");
 }
Config->WarnIfuncTextrel =
       Args.hasFlag(OPT_warn_ifunc_textrel, OPT_no_warn_ifunc_textrel, false);
   Config->WarnSymbolOrdering =
       Args.hasFlag(OPT_warn_symbol_ordering, OPT_no_warn_symbol_ordering, true);
   Config->ZCombreloc = getZFlag(Args, "combreloc", "nocombreloc", true);
   Config->ZCopyreloc = getZFlag(Args, "copyreloc", "nocopyreloc", true);
   Config->ZExecstack = getZFlag(Args, "execstack", "noexecstack", false);
   Config->ZGlobal = hasZOption(Args, "global");
   Config->ZHazardplt = hasZOption(Args, "hazardplt");
+  Config->ZIfuncnoplt = hasZOption(Args, "ifunc-noplt");
   Config->ZInitfirst = hasZOption(Args, "initfirst");
   Config->ZInterpose = hasZOption(Args, "interpose");
   Config->ZKeepTextSectionPrefix = getZFlag(
       Args, "keep-text-section-prefix", "nokeep-text-section-prefix", false);
   Config->ZNodefaultlib = hasZOption(Args, "nodefaultlib");
   Config->ZNodelete = hasZOption(Args, "nodelete");
   Config->ZNodlopen = hasZOption(Args, "nodlopen");
   Config->ZNow = getZFlag(Args, "now", "lazy", false);
void LinkerDriver::readConfigs(opt::InputArgList &Args) {
   if (Config->LTOPartitions == 0)
     error("--lto-partitions: number of threads must be > 0");
   if (Config->ThinLTOJobs == 0)
     error("--thinlto-jobs: number of threads must be > 0");
 
   if (Config->SplitStackAdjustSize < 0)
     error("--split-stack-adjust-size: size must be >= 0");
 
   // Parse ELF{32,64}{LE,BE} and CPU type.
   if (auto *Arg = Args.getLastArg(OPT_m)) {
     StringRef S = Arg->getValue();
     std::tie(Config->EKind, Config->EMachine, Config->OSABI) =
         parseEmulation(S);
     Config->MipsN32Abi = (S == "elf32btsmipn32" || S == "elf32ltsmipn32");
     Config->Emulation = S;
   }
 
   // Parse -hash-style={sysv,gnu,both}.

lld/ELF/Relocations.cpp

static void scanReloc(InputSectionBase &Sec, OffsetGetter &GetOffset, RelTy *&I,
   // Relax relocations.
   //
   // If we know that a PLT entry will be resolved within the same ELF module, we
   // can skip PLT access and directly jump to the destination function. For
   // example, if we are linking a main exectuable, all dynamic symbols that can
   // be resolved within the executable will actually be resolved that way at
   // runtime, because the main exectuable is always at the beginning of a search
   // list. We can leverage that fact.
-  if (!Sym.IsPreemptible && !Sym.isGnuIFunc()) {
+  if (!Sym.IsPreemptible && (!Sym.isGnuIFunc() || Config->ZIfuncnoplt)) {
     if (Expr == R_GOT_PC && !isAbsoluteValue(Sym))
       Expr = Target->adjustRelaxExpr(Type, RelocatedAddr, Expr);
     else
       Expr = fromPlt(Expr);
   }
 
   // If the relocation does not emit a GOT or GOTPLT entry but its computation
   // uses their addresses, we need GOT or GOTPLT to be created.
static void scanReloc(InputSectionBase &Sec, OffsetGetter &GetOffset, RelTy *&I,
   // Process some TLS relocations, including relaxing TLS relocations.
   // Note that this function does not handle all TLS relocations.
   if (unsigned Processed =
           handleTlsRelocation<ELFT>(Type, Sym, Sec, Offset, Addend, Expr)) {
     I += (Processed - 1);
     return;
   }
 
+  // We were asked not to generate PLT entries for ifuncs. Instead, pass the
+  // direct relocation on through.
+  if (Sym.isGnuIFunc() && Config->ZIfuncnoplt) {
+    Sym.ExportDynamic = true;
+    In.RelaDyn->addReloc(Type, &Sec, Offset, &Sym, Addend, R_ADDEND, Type);
+    return;
+  }
+
   // Non-preemptible ifuncs require special handling. First, handle the usual
   // case where the symbol isn't one of these.
   if (!Sym.isGnuIFunc() || Sym.IsPreemptible) {
     // If a relocation needs PLT, we create PLT and GOTPLT slots for the symbol.
     if (needsPlt(Expr) && !Sym.isInPlt())
       addPltEntry<ELFT>(In.Plt, In.GotPlt, In.RelaPlt, Target->PltRel, Sym);
 
     // Create a GOT slot if a relocation needs GOT.

lld/docs/ld.lld.1

 .\" Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 .\" See https://llvm.org/LICENSE.txt for license information.
 .\" SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 .\"
 .\" This man page documents only lld's ELF linking support, obtained originally
 .\" from FreeBSD.
-.Dd February 26, 2019
+.Dd May 6, 2019
 .Dt LD.LLD 1
 .Os
 .Sh NAME
 .Nm ld.lld
 .Nd ELF linker from the LLVM project
 .Sh SYNOPSIS
 .Nm ld.lld
 .Op Ar options

 .Dv PT_GNU_STACK
 segment.
 .It Cm global
 Sets the
 .Dv DF_1_GLOBAL flag in the
 .Dv DYNAMIC
 section.
 Different loaders can decide how to handle this flag on their own.
+.It Cm ifunc-noplt
+Do not emit PLT entries for ifunc symbols.
+Instead, emit text relocations referencing the resolver.
+This is an experimental optimization and only suitable for standalone
+environments where text relocations are permitted.
 .It Cm initfirst
 Sets the
 .Dv DF_1_INITFIRST
 flag to indicate the module should be initialized first.
 .It Cm interpose
 Set the
 .Dv DF_1_INTERPOSE
 flag to indicate to the runtime linker that the object is an interposer.

lld/test/ELF/gnu-ifunc-noplt-i386.s

+// REQUIRES: x86
+// RUN: llvm-mc -filetype=obj -triple=i686-pc-linux %S/Inputs/shared2-x86-64.s -o %t1.o
+// RUN: ld.lld %t1.o --shared -o %t.so
+// RUN: llvm-mc -filetype=obj -triple=i686-pc-linux %s -o %t.o
+// RUN: ld.lld -zifunc-noplt --hash-style=sysv %t.so %t.o -o %tout
+// RUN: llvm-objdump -d %tout | FileCheck %s --check-prefix=DISASM
+// RUN: llvm-readobj -r --dynamic-table %tout | FileCheck %s
+
+// Check that the IRELATIVE relocations are after the JUMP_SLOT in the plt
+// CHECK: Relocations [
+// CHECK-NEXT:   Section (4) .rel.dyn {
+// CHECK-NEXT:     0x401008 R_386_PLT32 bar
+// CHECK-NEXT:     0x401003 R_386_PLT32 foo
+// CHECK-NEXT:   }
+// CHECK-NEXT:   Section (5) .rel.plt {
+// CHECK-NEXT:     0x40300C R_386_JUMP_SLOT bar2
+// CHECK-NEXT:     0x403010 R_386_JUMP_SLOT zed2
+// CHECK-NEXT:   }
+
+// Check that a PLT header is written and the ifunc entries appear last
+// DISASM: Disassembly of section .text:
+// DISASM-EMPTY:
+// DISASM-NEXT: foo:
+// DISASM-NEXT:    401000:       c3      retl
+// DISASM:      bar:
+// DISASM-NEXT:    401001:       c3      retl
+// DISASM:      _start:
+// DISASM-NEXT:    401002:       e8 fc ff ff ff          calll   -4
+// DISASM-NEXT:    401007:       e8 fc ff ff ff          calll   -4
+// DISASM-NEXT:    40100c:       e8 1f 00 00 00          calll   31
+// DISASM-NEXT:    401011:       e8 2a 00 00 00          calll   42
+// DISASM-EMPTY:
+// DISASM-NEXT: Disassembly of section .plt:
+// DISASM-EMPTY:
+// DISASM-NEXT: .plt:
+// DISASM-NEXT:    401020:       ff 35 04 30 40 00       pushl   4206596
+// DISASM-NEXT:    401026:       ff 25 08 30 40 00       jmpl    *4206600
+// DISASM-NEXT:    40102c:       90      nop
+// DISASM-NEXT:    40102d:       90      nop
+// DISASM-NEXT:    40102e:       90      nop
+// DISASM-NEXT:    40102f:       90      nop
+// DISASM-EMPTY:
+// DISASM-NEXT:   bar2@plt:
+// DISASM-NEXT:    401030:       ff 25 0c 30 40 00       jmpl    *4206604
+// DISASM-NEXT:    401036:       68 00 00 00 00          pushl   $0
+// DISASM-NEXT:    40103b:       e9 e0 ff ff ff          jmp     -32 <.plt>
+// DISASM-EMPTY:
+// DISASM-NEXT:   zed2@plt:
+// DISASM-NEXT:    401040:       ff 25 10 30 40 00       jmpl    *4206608
+// DISASM-NEXT:    401046:       68 08 00 00 00          pushl   $8
+// DISASM-NEXT:    40104b:       e9 d0 ff ff ff          jmp     -48 <.plt>
+
+.text
+.type foo STT_GNU_IFUNC
+.globl foo
+foo:
+ ret
+
+.type bar STT_GNU_IFUNC
+.globl bar
+bar:
+ ret
+
+.globl _start
+_start:
+ call foo@plt
+ call bar@plt
+ call bar2@plt
+ call zed2@plt

lld/test/ELF/gnu-ifunc-noplt.s

+// REQUIRES: x86
+// RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %S/Inputs/shared2-x86-64.s -o %t1.o
+// RUN: ld.lld %t1.o --shared -o %t.so
+// RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
+// RUN: ld.lld -zifunc-noplt --hash-style=sysv %t.so %t.o -o %tout
+// RUN: llvm-objdump -d %tout | FileCheck %s --check-prefix=DISASM
+// RUN: llvm-readobj -r --dynamic-table %tout | FileCheck %s
+
+// Check that the IRELATIVE relocations are after the JUMP_SLOT in the plt XXX
+// CHECK: Relocations [
+// CHECK-NEXT:   Section (4) .rela.dyn {
+// CHECK-NEXT:     0x201008 R_X86_64_PLT32 bar 0xFFFFFFFFFFFFFFFC
+// CHECK-NEXT:     0x201003 R_X86_64_PLT32 foo 0xFFFFFFFFFFFFFFFC
+// CHECK-NEXT:   }
+// CHECK-NEXT:   Section (5) .rela.plt {
+// CHECK-NEXT:     0x203018 R_X86_64_JUMP_SLOT bar2 0x0
+// CHECK-NEXT:     0x203020 R_X86_64_JUMP_SLOT zed2 0x0
+// CHECK-NEXT:   }
+
+// Check that a PLT header is written and the ifunc entries appear last XXX
+// DISASM: Disassembly of section .text:
+// DISASM-EMPTY:
+// DISASM-NEXT: foo:
+// DISASM-NEXT:   201000:       c3      retq
+// DISASM:      bar:
+// DISASM-NEXT:   201001:       c3      retq
+// DISASM:      _start:
+// DISASM-NEXT:   201002:       e8 00 00 00 00          callq   0
+// DISASM-NEXT:   201007:       e8 00 00 00 00          callq   0
+// DISASM-NEXT:   20100c:       e8 1f 00 00 00          callq   31
+// DISASM-NEXT:   201011:       e8 2a 00 00 00          callq   42
+// DISASM-EMPTY:
+// DISASM-NEXT: Disassembly of section .plt:
+// DISASM-EMPTY:
+// DISASM-NEXT: .plt:
+// DISASM-NEXT:   201020:       ff 35 e2 1f 00 00       pushq   8162(%rip)
+// DISASM-NEXT:   201026:       ff 25 e4 1f 00 00       jmpq    *8164(%rip)
+// DISASM-NEXT:   20102c:       0f 1f 40 00     nopl    (%rax)
+// DISASM-EMPTY:
+// DISASM-NEXT:   bar2@plt:
+// DISASM-NEXT:   201030:       ff 25 e2 1f 00 00       jmpq    *8162(%rip)
+// DISASM-NEXT:   201036:       68 00 00 00 00          pushq   $0
+// DISASM-NEXT:   20103b:       e9 e0 ff ff ff          jmp     -32 <.plt>
+// DISASM-EMPTY:
+// DISASM-NEXT:   zed2@plt:
+// DISASM-NEXT:   201040:       ff 25 da 1f 00 00       jmpq    *8154(%rip)
+// DISASM-NEXT:   201046:       68 01 00 00 00          pushq   $1
+// DISASM-NEXT:   20104b:       e9 d0 ff ff ff          jmp     -48 <.plt>
+
+.text
+.type foo STT_GNU_IFUNC
+.globl foo
+foo:
+ ret
+
+.type bar STT_GNU_IFUNC
+.globl bar
+bar:
+ ret
+
+.globl _start
+_start:
+ call foo
+ call bar
+ call bar2
+ call zed2