Commit Graph

14328 Commits

Author SHA1 Message Date
Vincent Lee d695d0d6f6 [lld-macho] Optimize bind opcodes with multiple passes
In D105866, we used an intermediate container to store a list of opcodes. Here,
we use that data structure to help us perform optimization passes that would allow
a more efficient encoding of bind opcodes. Currently, the functionality mirrors the
optimization pass {1,2} done in ld64 for bind opcodes under optimization gate
to prevent slight regressions.

Reviewed By: int3, #lld-macho

Differential Revision: https://reviews.llvm.org/D105867
2021-07-15 20:52:46 -07:00
Vincent Lee f2b1264141 [lld-macho] Use intermediate arrays to store opcodes
We want to incorporate some of the optimization passes in bind opcodes from ld64.
This revision makes no functional changes but to start storing opcodes in intermediate
containers in preparation for implementing the optimization passes in a follow-up revision.

Differential Revision: https://reviews.llvm.org/D105866
2021-07-15 16:57:45 -07:00
Fangrui Song f8cb78e99a [ELF] Don't define __rela_iplt_start for -pie/-shared
`clang -fuse-ld=lld -static-pie -fpie` produced executable
currently crashes and this patch makes it work.

See https://sourceware.org/bugzilla/show_bug.cgi?id=27164
and https://sourceware.org/pipermail/libc-alpha/2021-July/128810.html

While it seems unreasonable to keep csu/libc-start.c ARCH_APPLY_IREL unclear in
static-pie mode and have an unneeded diff -u =(ld.bfd --verbose) =(ld.bfd -pie
--verbose) difference, glibc folks don't want to fix their code.
I feel sad about that but this patch can remove an iffy condition for lld/ELF
as well: `needsInterpSection()`.
2021-07-15 11:31:11 -07:00
Fangrui Song 80f9fd4ce3 [ELF][test] Rework non-preemptible ifunc tests 2021-07-15 11:31:05 -07:00
Fangrui Song aa3df8ddcd [test] Avoid llvm-readelf/llvm-readobj one-dash long options and deprecated aliases (e.g. --file-headers) 2021-07-15 10:26:21 -07:00
Wouter van Oortmerssen 4157b6033d [WebAssembly] Fixed LLD generation of 64-bit __wasm_apply_data_relocs
Differential Revision: https://reviews.llvm.org/D105863
2021-07-15 10:02:02 -07:00
Leonard Grey c931ff72bd [lld-macho] Add LTO cache support
This adds support for the lld-only `--thinlto-cache-policy` option, as well as
implementations for ld64's `-cache_path_lto`, `-prune_interval_lto`,
`-prune_after_lto`, and `-max_relative_cache_size_lto`.

Test is adapted from lld/test/ELF/lto/cache.ll

Differential Revision: https://reviews.llvm.org/D105922
2021-07-15 12:56:13 -04:00
Fangrui Song 7299c6f635 [test] Avoid llvm-nm one-dash long options 2021-07-15 09:50:36 -07:00
Fangrui Song 7de2173c2a [ELF] --fortran-common: prefer STB_WEAK to COMMON
The ELF specification says "The link editor honors the common definition and
ignores the weak ones." GNU ld and our Symbol::compare follow this, but the
--fortran-common code (D86142) made a mistake on the precedence.

Fixes https://bugs.llvm.org/show_bug.cgi?id=51082

Reviewed By: peter.smith, sfertile

Differential Revision: https://reviews.llvm.org/D105945
2021-07-14 10:18:30 -07:00
Alexander Shaposhnikov d21772fa21 [lld][MachO] Code cleanup
Make use of ArgList::getLastArgValue. NFC.

Test plan: make check-lld-macho

Differential revision: https://reviews.llvm.org/D105452
2021-07-14 04:33:09 -07:00
Alexander Yermolovich 24129fbc9a [LLD] Adding support for RELA for CG Profile.
This is a follow up to https://reviews.llvm.org/D104080, and ca3bdb57fa (diff-e64a48fabe31db213a631fdc5f2acb51bdddf3f16a8fb2928784f4c579229585). The implementation of  call graph profile was changed from a black box section to relocation approach. This was done to be compatible with post processing tools like strip/objcopy, and llvm equivalent. When they are invoked on object file before the final linking step with this new approach the symbol indices correctness is preserved.

The GNU binutils tools change the REL section to RELA section, unlike llvm tools. For example when strip -S is run on the ELF object files, as an intermediate step before linking. To preserve compatibility this patch extends implementation in LLD and ELFDumper to support both REL and RELA sections for call graph profile.

Reviewed By: MaskRay, jhenderson

Differential Revision: https://reviews.llvm.org/D105217
2021-07-13 13:56:30 -07:00
Hafiz Abid Qadeer fb9c5c3dce [lld][AMDGPU] Handle R_AMDGPU_REL16 relocation.
This patch is a followup patch to https://reviews.llvm.org/D105760 which adds this relocation. This handles the relocation in lld.

The s_branch family of instruction does the following:
PC = PC + signext(simm * 4) + 4

so we we do the opposite on the target address before writing it in the instruction stream.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D105761
2021-07-13 20:41:11 +01:00
Wouter van Oortmerssen b568c11b40 [WebAssembly] Fixed LLD generation of 64-bit __wasm_init_memory
Differential Revision: https://reviews.llvm.org/D105849
2021-07-12 15:26:11 -07:00
Nico Weber f21801dab2 [lld/mac] Implement -application_extension
Differential Revision: https://reviews.llvm.org/D105818
2021-07-12 13:42:16 -04:00
Nico Weber 396f2e9d6d [lld/mac] Make tbd files in one test valid
No behavior change, but ld64 can't load .tbd files without the
trailing `...`, so include them to make it easier to run tests
with l64 too.
2021-07-12 11:13:54 -04:00
Jez Ng 0fb299072c [lld-macho][nfc] Fix YAML input in compact-unwind-sym-relocs.s
* Adjust strsize so llvm-objdump doesn't complain about it extending
  past the end of file
* Remove symbol that was referencing a deleted section
* Adjust n_sect of the remaining `_main` symbol to point at the right
  section
2021-07-11 21:36:24 -04:00
Jez Ng 11a0d23650 [lld-macho][nfc] clang-format 2021-07-11 18:36:59 -04:00
Jez Ng 28a2102ee3 [lld-macho][nfc] Remove unnecessary llvm:: namespace prefixes 2021-07-11 18:36:53 -04:00
Jez Ng f6e84a84f9 [lld-macho][nfc] Avoid using std::map for PlatformKinds
The mappings we were using had a small number of keys, so a vector is
probably better. This allows us to remove the last usage of std::map in
our codebase.

I also used `removeSimulator` to simplify the code a bit further.

Reviewed By: #lld-macho, thakis

Differential Revision: https://reviews.llvm.org/D105786
2021-07-11 18:24:53 -04:00
Nico Weber c10947b5f8 [lld/mac] Unbreak objc.s after 6e05c1cd5f 2021-07-11 13:57:15 -04:00
Nico Weber 6e05c1cd5f [lld/mac] Always reference dyld_stub_binder when linked with libSystem
lld currently only references dyld_stub_binder when it's needed.
ld64 always references it when libSystem is linked.
Match ld64.

The (somewhat lame) motivation is that `nm` on a binary without any
export writes a "no symbols" warning to stderr, and this change makes
it so that every binary in practice has at least a reference to
dyld_stub_binder, which suppresses that.

Every "real" output file will reference dyld_stub_binder, so most
of the time this shouldn't make much of a difference. And if you
really don't want to have this reference for whatever reason, you
can stop passing -lSystem, like you have to for ld64 anyways.

(After linking any dylib, we dump the exported list of symbols to
a txt file with `nm` and only relink downstream deps if that txt
file changes. A nicer fix is to make lld optionally write .tbd files
with the public interface of a linked dylib and use that instead,
but for now the txt files are what we do.)

Differential Revision: https://reviews.llvm.org/D105782
2021-07-11 13:37:48 -04:00
Nico Weber 10e28a7484 [lld/mac] Use normal Undefined machinery for dyld_stub_binder lookup
This is for aesthetic reasons, I'm not aware of anything that needs
this in practice. It does have a few effects:

- `-undefined dynamic_lookup` now has an effect for dyld_stub_binder.
  This matches ld64.

- `-U dyld_stub_binder` now works like you'd expect (it doesn't work in ld64).

- The error message for a missing dyld_stub_binder symbol now looks like
  other undefined reference symbols, it changes from

      symbol dyld_stub_binder not found (normally in libSystem.dylib). Needed to perform lazy binding.

  to

      error: undefined symbol: dyld_stub_binder
      >>> referenced by lazy binding (normally in libSystem.dylib)

Also add test coverage for that error message.

But in practice, this should have no interesting effects since everything links
in dyld_stub_binder via libSystem anyways.

Differential Revision: https://reviews.llvm.org/D105781
2021-07-11 12:48:59 -04:00
Jez Ng d5c0b9c848 [lld-macho][nfc] Expand the compact unwind symbol reloc test
Add a bit more detail to the comments, and check that the final binary
does indeed have a `__unwind_info` section (D105557 previosly regressed
this).

Also rename the test to emphasize that we are testing relocations
compact unwind, not relocations in general.
2021-07-11 00:35:05 -04:00
Vy Nguyen 3822e3d5b0 [lld-macho] Fix bug in handling unwind info from ld -r
Two changess:
- Drop assertions that all symbols are in GOT
- Set allEntriesAreOmitted correctly

Related bug: 50812

Differential Revision: https://reviews.llvm.org/D105364
2021-07-09 22:44:51 -04:00
Wouter van Oortmerssen 9647a6f719 [WebAssembly] Added initial type checker to MC Assembler
This to protect against non-sensical instruction sequences being assembled,
which would either cause asserts/crashes further down, or a Wasm module being output that doesn't validate.

Unlike a validator, this type checker is able to give type-errors as part of the parsing process, which makes the assembler much friendlier to be used by humans writing manual input.

Because the MC system is single pass (instructions aren't even stored in MC format, they are directly output) the type checker has to be single pass as well, which means that from now on .globaltype and .functype decls must come before their use. An extra pass is added to Codegen to collect information for this purpose, since AsmPrinter is normally single pass / streaming as well, and would otherwise generate this information on the fly.

A `-no-type-check` flag was added to llvm-mc (and any other tools that take asm input) that surpresses type errors, as a quick escape hatch for tests that were not intended to be type correct.

This is a first version of the type checker that ignores control flow, i.e. it checks that types are correct along the linear path, but not the branch path. This will still catch most errors. Branch checking could be added in the future.

Differential Revision: https://reviews.llvm.org/D104945
2021-07-09 14:07:25 -07:00
Simon Pilgrim 1440d4564f Fix MSVC "not all control paths return a value" warning. NFCI. 2021-07-09 12:07:34 +01:00
Alex Richardson cc7cb9523e [ELF][AArch64] Write addends for TLSDESC relocations with -z rel
Since D100490 this case is diagnosed for -z rel. This commit implements
R_AARCH64_TLSDESC cases for AArch64::getImplicitAddend() and
AArch64::relocate(). However, there are probably further relocation types
that need to be handled for full support of -z rel.

Fixes https://bugs.llvm.org/show_bug.cgi?id=47009

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D100544
2021-07-09 10:41:41 +01:00
Alex Richardson 97fe637539 [ELF] Implement RISCV::getImplicitAddend()
This allows checking dynamic relocation addends for -z rel and
--apply-dynamic-relocs output.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D101455
2021-07-09 10:41:40 +01:00
Alex Richardson e564932842 [ELF] Write R_RISCV_IRELATIVE addends with -z rel
I found this missing case with the new --check-dynamic-relocation flag
while running the lld tests with --apply-dynamic-relocs enabled by default.

This is the same as D101452 just for RISC-V

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D101454
2021-07-09 10:41:40 +01:00
Alex Richardson 79332fb722 [ELF] Write R_X86_64_IRELATIVE addends with -z rel
I found this missing case with the new --check-dynamic-relocation flag
while running the lld tests with --apply-dynamic-relocs enabled by default.

This also fixes a broken CHECK in lld/test/ELF/x86-64-gotpc-relax.s:
The test wasn't using CHECK-NEXT, so it was passing despite the output
actually containing relocations. I am not sure when this changed, but I
think this behaviour is correct.

Found with D101450 + enabling --apply-dynamic-relocs by default.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D101452
2021-07-09 10:41:40 +01:00
Alex Richardson f4b0c9abfb [ELF] Implement X86_64::getImplicitAddend()
This allows checking dynamic relocation addends for -z rel and
--apply-dynamic-relocs output.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D101451
2021-07-09 10:41:40 +01:00
Alex Richardson 35c5e564e6 [ELF] Check the Elf_Rel addends for dynamic relocations
There used to be many cases where addends for Elf_Rel were not emitted in
the final object file (mostly when building for MIPS64 since the input .o
files use RELA but the output uses REL). These cases have been fixed since,
but this patch adds a check to ensure that the written values are correct.
It is based on a previous patch that I added to the CHERI fork of LLD since
we were using MIPS64 as a baseline. The work has now almost entirely
shifted to RISC-V and Arm Morello (which use Elf_Rela), but I thought
it would be useful to upstream our local changes anyway.

This patch adds a (hidden) command line flag --check-dynamic-relocations
that can be used to enable these checks. It is also on by default in
assertions builds for targets that handle all dynamic relocations kinds
that LLD can emit in Target::getImplicitAddend(). Currently this is
enabled for ARM, MIPS, and I386.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D101450
2021-07-09 10:41:40 +01:00
Alex Richardson 6d87ca08ae [ELF] Refactor DynamicReloc to fix incorrect relocation addends
This patch changes the DynamicReloc class to store an enum instead
of the overloaded useSymVA member to make it easier to understand
and fix incorrect addends being written in some corner cases. The
change is motivated by a follow-up review that checks the value of
implicit Elf_Rel addends written to the output file.

This patch fixes an incorrect output when using `-z rela` for i386 files
with R_386_GOT32 relocations (not that this really matters since it's an
unsupported configuration).
Storing the relocation expression kind also addresses an incorrect addend
FIXME in ppc64-abs64-dyn.s introduced in D63383.

DynamicReloc now also has a special case for the MIPS TLS relocations
(DynamicReloc::AgainstSymbolWithTargetVA) since the
R_MIPS_TLS_TPREL{32/64} the symbol VA to the GOT for preemptible
symbols. I'm not sure if the symbol value actually should be written
for R_MIPS_TLS_TPREL32, but this patch does not attempt to change
that behaviour.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D100490
2021-07-09 10:41:40 +01:00
David Blaikie 1def2579e1 PR51018: Remove explicit conversions from SmallString to StringRef to future-proof against C++23
C++23 will make these conversions ambiguous - so fix them to make the
codebase forward-compatible with C++23 (& a follow-up change I've made
will make this ambiguous/invalid even in <C++23 so we don't regress
this & it generally improves the code anyway)
2021-07-08 13:37:57 -07:00
Mikael Holmen 21fd875952 [lld/mac] Fix warning about unused variable [NFC]
Change "dyn_cast" to "isa" to get rid of the unused
variable "bitcodeFile".

gcc warned with

lld/MachO/Driver.cpp:531:17: warning: unused variable 'bitcodeFile' [-Wunused-variable]
531 |       if (auto *bitcodeFile = dyn_cast<BitcodeFile>(file)) {
    |                 ^~~~~~~~~~~
2021-07-08 09:46:30 +02:00
Thomas Lively 0fd5e7b2d8 [WebAssembly][lld] Fix segfault on .bss sections in mapfile
When memory is declared in the Wasm module, we rely on the implicit zero
initialization behavior and do not explicitly output .bss sections. The means
that they do not have associated `outputSec` entries, which was causing
segfaults in the mapfile support. Fix the issue by guarding against null
`outputSec` and falling back to using a zero offset.

Differential Revision: https://reviews.llvm.org/D102951
2021-07-07 23:31:48 -07:00
Jeremy Drake 7a7da69fbe [LLD] [COFF] Avoid thread exhaustion on 32-bit Windows host
LLD on 32-bit Windows would frequently fail on large projects with
an exception "thread constructor failed: Exec format error".  The stack
trace pointed to this usage of std::async, and looking at the
implementation in libc++ it seems using std::async with
std::launch::async results in the immediate creation of a new thread
for every call.  This could result in a potentially unbounded number
of threads, depending on the number of input files.  This seems to
be hitting some limit in 32-bit Windows host.

I took the easy route, and only use threads on 64-bit Windows, not all
Windows as before.  I was thinking a more proper solution might
involve using a thread pool rather than blindly spawning any number
of new threads, but that may have other unforeseen consequences.

Reviewed By: rnk

Differential Revision: https://reviews.llvm.org/D105506
2021-07-07 22:00:18 +03:00
Vy Nguyen e25a384055 [lld-macho][nfc] Rename test file to be more descriptive (rather than referencing the bug number)
Differential Revision: https://reviews.llvm.org/D105559
2021-07-07 13:15:55 -04:00
Nico Weber 8a7b5ebf4d [lld/mac] Don't crash when dead-stripping removes all unwind info
If the input has compact unwind info but all of it is removed
after dead stripping, we would crash. Now we don't write any
__unwind_info section at all, like ld64.

This is a bit awkward to implement because we only know the final
state of unwind info after UnwindInfoSectionImpl<Ptr>::finalize(),
which is called after sections are added. So add a small amount of
bookkeeping to relocateCompactUnwind() instead (which runs earlier)
so that we can predict what finalize() will do before it runs.

Fixes PR51010.

Differential Revision: https://reviews.llvm.org/D105557
2021-07-07 13:05:40 -04:00
Nico Weber d7e65757ed [lld/mac] Tweak reserve() argument in unwind code
addEntriesForFunctionsWithoutUnwindInfo() can add entries to cuVector, so
cuCount can be stale. Use cuVector.size() instead.

No behavior change.
2021-07-07 11:44:22 -04:00
Nico Weber 76f734040a [lld/mac] Give several LTO tests an "lto-" prefix
Differential Revision: https://reviews.llvm.org/D105476
2021-07-06 15:23:42 -04:00
Nico Weber 3eb2fc4b50 [lld/mac] Partially implement -export_dynamic
This implements the part of -export_dynamic that adds external
symbols as dead strip roots even for executables.

It does not yet implement the effect -export_dynamic has for LTO.
I tried just replacing `config->outputType != MH_EXECUTE` with
`(config->outputType != MH_EXECUTE || config->exportDynamic)` in
LTO.cpp, but then local symbols make it into the symbol table too,
which is too much (and also doesn't match ld64). So punt on this
for now until I understand it better.
(D91583 may or may not be related too).

Differential Revision: https://reviews.llvm.org/D105482
2021-07-06 11:22:18 -04:00
Nico Weber 64be5b7d87 [lld/mac] Implement -arch_multiple
This is the other flag clang passes when calling clang with two -arch
flags (which means with this, `clang -arch x86_64 -arch arm64 -fuse-ld=lld ...`
now no longer prints any warnings \o/). Since clang calls the linker several
times in that setup, it's not clear to the user from which invocation the
errors are. The flag's help text is

    Specifies that the linker should augment error and warning messages
    with the architecture name.

In ld64, the only effect of the flag is that undefined symbols are prefaced
with

    Undefined symbols for architecture x86_64:

instead of the usual "Undefined symbols:". So for now, let's add this
only to undefined symbol errors too. That's probably the most common
linker diagnostic.

Another idea would be to prefix errors and warnings with "ld64.lld(x86_64):"
instead of the usual "ld64.lld:", but I'm not sure if people would
misunderstand that as a comment about the arch of ld itself.
But open to suggestions on what effect this flag should have :) And we
don't have to get it perfect now, we can iterate on it.

Differential Revision: https://reviews.llvm.org/D105450
2021-07-06 00:25:18 -04:00
Nico Weber 2c25f39fcc [lld/mac] Implement -final_output
This is one of two flags clang passes to the linker when giving calling
clang with multiple -arch flags.

I think it'd make sense to also use finalOutput instead of outputFile
in CodeSignatureSection() and when replacing @executable_path, but
ld64 doesn't do that, so I'll at least put those in separate commits.

Differential Revision: https://reviews.llvm.org/D105449
2021-07-05 20:06:26 -04:00
Nico Weber db64306d99 [lld/mac] Implement -umbrella
I think this is an old way for doing what is done with
-reexport_library these days, but it's e.g. still used in libunwind's
build (the opensource.apple.com one, not the llvm one).

Differential Revision: https://reviews.llvm.org/D105448
2021-07-05 20:06:25 -04:00
Jez Ng 718c32175b [lld-macho] Only emit one BIND_OPCODE_SET_SYMBOL per symbol
Size-wise, BIND_OPCODE_SET_SYMBOL_TRAILING_FLAGS_IMM is the most
expensive opcode, since it comes with an associated symbol string. We
were previously emitting it once per binding, instead of once per
symbol. This diff groups all bindings for a given symbol together and
ensures we only emit one such opcode per symbol. This matches ld64's
behavior.

While this is a relatively small win on chromium_framework (-72KiB), for
programs that have more dynamic bindings, the difference can be quite
large.

This change is perf-neutral when linking chromium_framework.

Reviewed By: #lld-macho, thakis

Differential Revision: https://reviews.llvm.org/D105075
2021-07-05 20:00:19 -04:00
Jez Ng 4aaf878750 [lld-macho][nfc] Add REQUIRES: x86 to test
I didn't realize that llvm-objdump's features were arch-specific.

This should fix the non-x86 buildbots.
2021-07-05 03:40:54 -04:00
Jez Ng bcaf57cae8 [lld-macho] Parse relocations quickly by assuming sorted order
clang and gcc both seem to emit relocations in reverse order of
address. That means we can match relocations to their containing
subsections in `O(relocs + subsections)` rather than the `O(relocs *
log(subsections))` that our previous binary search implementation
required.

Unfortunately, `ld -r` can still emit unsorted relocations, so we have a
fallback code path for that (less common) case.

Numbers for linking chromium_framework on my 3.2 GHz 16-Core Intel Xeon W:

      N           Min           Max        Median           Avg        Stddev
  x  20          4.04          4.11         4.075        4.0775   0.018027756
  +  20          3.95          4.02          3.98         3.985   0.020900768
  Difference at 95.0% confidence
          -0.0925 +/- 0.0124919
          -2.26855% +/- 0.306361%
          (Student's t, pooled s = 0.0195172)

Reviewed By: #lld-macho, thakis

Differential Revision: https://reviews.llvm.org/D105410
2021-07-05 01:13:44 -04:00
Nico Weber 9e24979d73 [lld/mac] Fix function offset on 1st-level unwind table sentinel
Two bugs:
1. This tries to take the address of the last symbol plus the length
   of the last symbol. However, the sorted vector is cuPtrVector,
   not cuVector. Also, cuPtrVector has tombstone values removed
   and cuVector doesn't. If there was a stripped value at the end,
   the "last" element's value was UINT64_MAX, which meant the
   sentinel value was one less than the length of that "last"
   dead symbol.

2. We have to subtract in.header->addr. For 64-bit binaries that's
   (1 << 32) and functionAddress is 32-bit so this is a no-op, but
   for 32-bit binaries the sentinel's value was too large.

I believe this has no effect in practice since the first-level
binary search code in libunwind (in UnwindCursor.hpp) does:

    uint32_t low = 0;
    uint32_t high = sectionHeader.indexCount();
    uint32_t last = high - 1;
    while (low < high) {
      uint32_t mid = (low + high) / 2;
        if ((mid == last) ||
            (topIndex.functionOffset(mid + 1) > targetFunctionOffset)) {
          low = mid;
          break;
        } else {
        low = mid + 1;
      }

So the address of the last entry in the first-level table isn't really
checked -- except for the very end, but the check against `last` means
we just run the loop once more than necessary. But it makes `unwinddump` output
look less confusing, and it's what it looks was the intention here.

(No test since I can't think of a way to make FileCheck check that one
number is larger than another.)

Differential Revision: https://reviews.llvm.org/D105404
2021-07-04 18:06:20 -04:00
Nico Weber d2d6da3011 [lld/mac] Don't crash on 32-bit output binaries when dead-stripping
Fixes PR50974.

Differential Revision: https://reviews.llvm.org/D105399
2021-07-04 18:03:31 -04:00