Commit Graph

6946 Commits

Author SHA1 Message Date
Fangrui Song c53a5eebb1 [ELF][test] Add -DAG
The guid of a local linkage variable has the module path encoded, so the
order between a local linkage variable and a non-local linkage variable
isn't guaranteed.
2021-07-20 15:27:52 -07:00
Vincent Lee 33ab995617 Recommit "[lld-macho] Use DO_BIND_ADD_ADDR_IMM_SCALED for bind opcodes"
Implement pass 3 of bind opcodes from ld64 (which supports both 32-bit and 64-bit).
Pass 3 implementation condenses BIND_OPCODE_DO_BIND_ADD_ADDR_ULEB opcode
to BIND_OPCODE_DO_BIND_ADD_ADDR_IMM_SCALED.  This change is already behind an
O2 flag so it shouldn't impact current performance. I verified ld64's output with x86_64 LLD
and they were both emitting the same optimized bind opcodes (although in a slightly different
order). Tested with arm64_32 LLD and compared that with x86 LLD that the order of the bind
opcodes are the same (offset values are different which should be expected).

Reviewed By: int3, #lld-macho, MaskRay

Differential Revision: https://reviews.llvm.org/D106128
2021-07-20 13:45:24 -07:00
Fangrui Song db5e078690 [LTO] Add SelectionKind to IRSymtab and use it in ld.lld/LLVMgold
In PGO, a C++ external linkage function `foo` has a private counter
`__profc_foo` and a private `__profd_foo` in a `comdat nodeduplicate`.

A `__attribute__((weak))` function `foo` has a weak hidden counter `__profc_foo`
and a private `__profd_foo` in a `comdat nodeduplicate`.

In `ld.lld a.o b.o`, say a.o defines an external linkage `foo` and b.o
defines a weak `foo`. Currently we treat `comdat nodeduplicate` as `comdat any`,
ld.lld will incorrectly consider `b.o:__profc_foo` non-prevailing.  In the worst
case when `b.o:__profd_foo` is retained and `b.o:__profc_foo` isn't, there will
be dangling reference causing an `undefined hidden symbol` error.

Add SelectionKind to `Comdat` in IRSymtab and let linkers ignore nodeduplicate comdat.

Differential Revision: https://reviews.llvm.org/D106228
2021-07-20 13:22:00 -07:00
Sam Clegg d51f74acdf [lld][WebAssembly] Error on import of TLS symbols in shared libraries
In https://reviews.llvm.org/D102044 we made exporting a TLS symbol
into an error, but we also want to error on import.

See https://github.com/emscripten-core/emscripten/issues/14461

Differential Revision: https://reviews.llvm.org/D106385
2021-07-20 12:36:03 -07:00
Fangrui Song 88e2268a34 Revert D106128 "[lld-macho] Use DO_BIND_ADD_ADDR_IMM_SCALED for bind opcodes"
This reverts commit 321b2bef09.

`for (BindIR *p = &opcodes[0]; p->opcode != BIND_OPCODE_DONE; ++p) {` has a heap-buffer-overflow with test/MachO/bind-opcodes.
2021-07-19 18:13:52 -07:00
Fangrui Song 16aac493e5 Revert D105519 "[WebAssembly] Deduplicate imports of the same module name, field name, and type" and its followup
This reverts commit 4ae575b999 and 9b965b37c7.

There is an use-of-uninitialized-value bug in the `else` branch in ImportSection::addImport.
2021-07-19 17:09:01 -07:00
Vincent Lee 321b2bef09 [lld-macho] Use DO_BIND_ADD_ADDR_IMM_SCALED for bind opcodes
Implement pass 3 of bind opcodes from ld64 (which supports both 32-bit and 64-bit).
Pass 3 implementation condenses BIND_OPCODE_DO_BIND_ADD_ADDR_ULEB opcode
to BIND_OPCODE_DO_BIND_ADD_ADDR_IMM_SCALED.  This change is already behind an
O2 flag so it shouldn't impact current performance. I verified ld64's output with x86_64 LLD
and they were both emitting the same optimized bind opcodes (although in a slightly different
order). Tested with arm64_32 LLD and compared that with x86 LLD that the order of the bind
opcodes are the same (offset values are different which should be expected).

Reviewed By: int3, #lld-macho

Differential Revision: https://reviews.llvm.org/D106128
2021-07-19 16:18:33 -07:00
Derek Schuff ad1f5457d2 [WebAssembly] Generate R_WASM_FUNCTION_OFFSET relocs in debuginfo sections
Debug info sections need R_WASM_FUNCTION_OFFSET_I32 relocs (with FK_Data_4 fixup
kinds) to refer to functions (instead of R_WASM_TABLE_INDEX as is used in data
sections). Usually this is done in a convoluted way, with unnamed temp data
symbols which target the start of the function, in which case
WasmObjectWriter::recordRelocation converts it to use the section symbol
instead. However in some cases the function can actually be undefined; in this
case the dwarf generator uses the function symbol (a named undefined function
symbol) instead. In that case the section-symbol transform doesn't work and we
need to generate the correct reloc type a different way. In this change
WebAssemblyWasmObjectWriter::getRelocType takes the fixup section type into
account to choose the correct reloc type.

Fixes PR50408
Differential Revision: https://reviews.llvm.org/D103557
2021-07-19 14:02:33 -07:00
Nick Fitzgerald 4ae575b999 [WebAssembly] Deduplicate imports of the same module name, field name, and type
When two symbols import the same thing, only one import should be emitted in the Wasm file.

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

Reviewed By: sbc100

Differential Revision: https://reviews.llvm.org/D105519
2021-07-19 13:59:02 -07:00
Leonard Grey 6ef37b640d [lld/mac] Add test for --lto-O
This belongs to fe08e9c487, I (thakis) forgot to `git add` it back then.

Differential Revision: https://reviews.llvm.org/D105223
2021-07-19 16:45:33 -04:00
Nico Weber fbb45947b2 [lld/mac] Resolve defined symbols before undefined symbols
Ports https://reviews.llvm.org/D95985 to the MachO port.
Happens to fix PR51135; see that bug for details.
Also makes lld's behavior match ld64 for the included test case.

Differential Revision: https://reviews.llvm.org/D106293
2021-07-19 16:37:41 -04:00
Nico Weber bcbb3066ce [lld/mac] Change load command order to be more like ld64
No meaningful behavior change. Makes diffing `otool -l` output a bit easier.

Differential Revision: https://reviews.llvm.org/D106219
2021-07-19 15:04:32 -04:00
Jez Ng 428a7c1b38 [lld-macho] Have ICF operate on all sections at once
ICF previously operated only within a given OutputSection. We would
merge all CFStrings first, then merge all regular code sections in a
second phase. This worked fine since CFStrings would never reference
regular `__text` sections. However, I would like to expand ICF to merge
functions that reference unwind info. Unwind info references the LSDA
section, which can in turn reference the `__text` section, so we cannot
perform ICF in phases.

In order to have ICF operate on InputSections spanning multiple
OutputSections, we need a way to distinguish InputSections that are
destined for different OutputSections, so that we don't fold across
section boundaries. We achieve this by creating OutputSections early,
and setting `InputSection::parent` to point to them. This is what
LLD-ELF does. (This change should also make it easier to implement the
`section$start$` symbols.)

This diff also folds InputSections w/o checking their flags, which I
think is the right behavior -- if they are destined for the same
OutputSection, they will have the same flags in the output (even if
their input flags differ). I.e. the `parent` pointer check subsumes the
`flags` check. In practice this has nearly no effect (ICF did not become
any more effective on chromium_framework).

I've also updated ICF.cpp's block comment to better reflect its current
status.

Reviewed By: #lld-macho, smeenai

Differential Revision: https://reviews.llvm.org/D105641
2021-07-17 13:42:51 -04:00
Fangrui Song fa3231eb18 [COFF][test] Fix llvm-readobj tests 2021-07-16 13:28:46 -07:00
Fangrui Song 8f806d5f52 [test] Avoid llvm-readelf/llvm-readobj one-dash long options 2021-07-16 12:03:07 -07:00
Fangrui Song 3c9d86f951 [ELF][test] Avoid llvm-readelf/llvm-readobj one-dash long options 2021-07-16 10:02:47 -07:00
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
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 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
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
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 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
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
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 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