[MachO] Fix dead-stripping __eh_frame

This section is marked S_ATTR_LIVE_SUPPORT in input files, which meant
that on arm64, we were unnecessarily preserving FDEs if we e.g. had
multiple weak definit

[MachO] Fix dead-stripping __eh_frame

This section is marked S_ATTR_LIVE_SUPPORT in input files, which meant
that on arm64, we were unnecessarily preserving FDEs if we e.g. had
multiple weak definitions for a function. Worse, we would actually
produce an invalid `__eh_frame` section in that case, because the CIE
associated with the unnecessary FDE would still get dead-stripped and
we'd end up with a dangling FDE. We set up associations from functions
to their FDEs, so dead-stripping will just work naturally, and we can
clear S_ATTR_LIVE_SUPPORT from our input `__eh_frame` sections to fix
dead-stripping.

Reviewed By: #lld-macho, int3

Differential Revision: https://reviews.llvm.org/D132489

(cherry picked from commit a745e47900dde15c180d5caea7a1d292ca809eb1)

show more ...

[lld-macho] Support EH frame pointer encodings that use sdata4

Previously we only supporting using the system pointer size (aka the
`absptr` encoding) because `llvm-mc`'s CFI directives always gener

[lld-macho] Support EH frame pointer encodings that use sdata4

Previously we only supporting using the system pointer size (aka the
`absptr` encoding) because `llvm-mc`'s CFI directives always generate EH
frames with that encoding. But libffi uses 4-byte-encoded, hand-rolled
EH frames, so this patch adds support for it.

Fixes #56576.

Reviewed By: #lld-macho, oontvoo

Differential Revision: https://reviews.llvm.org/D130804

(cherry picked from commit 6c9f6812523a706c11a12e6cb4119b0cf67bbb21)

show more ...

[lld/mac] Add support for $ld$previous symbols with explicit symbol name

A symbol `$ld$previous$/Another$1.2.3$1$3.0$14.0$_xxx$` means
"pretend symbol `_xxx` is in dylib `/Another` with version `1.2

[lld/mac] Add support for $ld$previous symbols with explicit symbol name

A symbol `$ld$previous$/Another$1.2.3$1$3.0$14.0$_xxx$` means
"pretend symbol `_xxx` is in dylib `/Another` with version `1.2.3`
if the deployment target is between `3.0` and `14.0` and we're
targeting platform `1` (ie macOS)".

This means dylibs can now inject synthetic dylibs into the link, so
DylibFile needs to grow a 3rd constructor.

The only other interesting thing is that such an injected dylib
counts as a use of the original dylib. This patch gets this mostly
right (if _only_ `$ld$previous` symbols are used from a dylib,
we don't add a dep on the dylib itself, matching ld64), but one case
where we don't match ld64 yet is that ld64 even omits the original
dylib when linking it with `-needed-l`. Lld currently still adds a load
command for the original dylib in that case. (That's for a future
patch.)

Fixes #56074.

Differential Revision: https://reviews.llvm.org/D130725

(cherry picked from commit 241f0e8b76d544a4a07a7f775b8421632539be19)

show more ...

Reland "[lld-macho] Implement -load_hidden"

This flag was introduced in ld64-609. It instructs the linker to link to
a static library while treating its symbols as if they had hidden
visibility. Thi

Reland "[lld-macho] Implement -load_hidden"

This flag was introduced in ld64-609. It instructs the linker to link to
a static library while treating its symbols as if they had hidden
visibility. This is useful when building a dylib that links to static
libraries but we don't want the symbols from those to be exported.

Closes #51505

This reland adds bitcode file handling, so we won't get any compile
errors due to BitcodeFile::forceHidden being unused.

Differential Revision: https://reviews.llvm.org/D130473

show more ...

Revert "[lld-macho] Implement -load_hidden"

This reverts commit 4c79e1a3f4eb790f40239833ae237e828ce07386.

Broke this bot: https://lab.llvm.org/buildbot/#builders/57/builds/20319

[lld-macho] Implement -load_hidden

This flag was introduced in ld64-609. It instructs the linker to link to
a static library while treating its symbols as if they had hidden
visibility. This is usef

[lld-macho] Implement -load_hidden

This flag was introduced in ld64-609. It instructs the linker to link to
a static library while treating its symbols as if they had hidden
visibility. This is useful when building a dylib that links to static
libraries but we don't want the symbols from those to be exported.

Closes #51505

Differential Revision: https://reviews.llvm.org/D130473

show more ...

[lld-macho] Fold __objc_imageinfo sections

Previously, we treated it as a regular ConcatInputSection. However, ld64
actually parses its contents and uses that to synthesize a single image
info struc

[lld-macho] Fold __objc_imageinfo sections

Previously, we treated it as a regular ConcatInputSection. However, ld64
actually parses its contents and uses that to synthesize a single image
info struct, generating one 8-byte section instead of `8 * number of
object files with ObjC code`.

I'm not entirely sure what impact this section has on the runtime, so I
just tried to follow ld64's semantics as closely as possible in this
diff. My main motivation though was to reduce binary size.

No significant perf change on chromium_framework on my 16-core Mac Pro:

base diff difference (95% CI)
sys_time 1.764 ± 0.062 1.748 ± 0.032 [ -2.4% .. +0.5%]
user_time 5.112 ± 0.104 5.106 ± 0.046 [ -0.9% .. +0.7%]
wall_time 6.111 ± 0.184 6.085 ± 0.076 [ -1.6% .. +0.8%]
samples 30 32

Reviewed By: #lld-macho, thakis

Differential Revision: https://reviews.llvm.org/D130125

show more ...

[lld-macho] Fix segfault when handling LTO + object file weak defs

which occurs when there are EH frames present in the object file's weak
def.

Reviewed By: abrachet

Differential Revision: https:/

[lld-macho] Fix segfault when handling LTO + object file weak defs

which occurs when there are EH frames present in the object file's weak
def.

Reviewed By: abrachet

Differential Revision: https://reviews.llvm.org/D130409

show more ...

[lld-macho] Fix LOH parsing segfault

`advanceSubsection()` didn't account for the possibility that a section
could have no subsections.

Reviewed By: #lld-macho, thakis, BertalanD

Differential Revi

[lld-macho] Fix LOH parsing segfault

`advanceSubsection()` didn't account for the possibility that a section
could have no subsections.

Reviewed By: #lld-macho, thakis, BertalanD

Differential Revision: https://reviews.llvm.org/D130288

show more ...

[lld-macho] Fix assertion when two symbols at same addr have unwind info

If there are multiple symbols at the same address, our unwind info
implementation assumes that we always register unwind entr

[lld-macho] Fix assertion when two symbols at same addr have unwind info

If there are multiple symbols at the same address, our unwind info
implementation assumes that we always register unwind entries to a
single canonical symbol.

This assumption was violated by the `registerEhFrame` code.

Fixes #56570.

Reviewed By: #lld-macho, thakis

Differential Revision: https://reviews.llvm.org/D130208

show more ...

[lld-macho][NFC] Remove redundant StringRef construction

It's only used in one branch, so we were unnecessarily calculating the
length of many symbol names.

Tiny speedup when linking chromium_frame

[lld-macho][NFC] Remove redundant StringRef construction

It's only used in one branch, so we were unnecessarily calculating the
length of many symbol names.

Tiny speedup when linking chromium_framework on my M1 Mac mini:

x before.txt
+ after.txt

N Min Max Median Avg Stddev
x 10 3.9917109 4.0418 4.0318099 4.0203902 0.021459873
+ 10 3.944725 4.053988 3.9708955 3.9825602 0.037257609
Difference at 95.0% confidence
-0.03783 +/- 0.0285663
-0.940953% +/- 0.710536%
(Student's t, pooled s = 0.0304028)

Differential Revision: https://reviews.llvm.org/D130234

show more ...

[lld-macho] Fold cfstrings with --deduplicate-literals

Similar to cstrings ld64 always deduplicates cfstrings. This was already
being done when enabling ICF, but for debug builds you may want to fli

[lld-macho] Fold cfstrings with --deduplicate-literals

Similar to cstrings ld64 always deduplicates cfstrings. This was already
being done when enabling ICF, but for debug builds you may want to flip
this on if you cannot eliminate your instances of this, so this change
makes --deduplicate-literals also apply to cfstrings.

Differential Revision: https://reviews.llvm.org/D130134

show more ...

[lld-macho] Support folding of functions with identical LSDAs

To do this, we need to slice away the LSDA pointer, just like we are
slicing away the functionAddress pointer.

No observable difference

[lld-macho] Support folding of functions with identical LSDAs

To do this, we need to slice away the LSDA pointer, just like we are
slicing away the functionAddress pointer.

No observable difference in perf on chromium_framework:

base diff difference (95% CI)
sys_time 1.769 ± 0.068 1.761 ± 0.065 [ -2.7% .. +1.8%]
user_time 9.517 ± 0.110 9.528 ± 0.116 [ -0.6% .. +0.8%]
wall_time 8.291 ± 0.174 8.307 ± 0.183 [ -1.1% .. +1.5%]
samples 21 25

Reviewed By: #lld-macho, thakis

Differential Revision: https://reviews.llvm.org/D129830

show more ...

[lld-macho][nfc] Add more tests + comments around ICF + unwind info interaction

While working on {D129830}, I realized that our handling of ICF +
eh_frame combined was untested. Additionally I reali

[lld-macho][nfc] Add more tests + comments around ICF + unwind info interaction

While working on {D129830}, I realized that our handling of ICF +
eh_frame combined was untested. Additionally I realized that the comment
explaining why we were safely slicing away the functionAddress reloc
from our compact unwind entries was... insufficient and slightly
misleading. I've tried to clarify it.

Reviewed By: #lld-macho, thevinster

Differential Revision: https://reviews.llvm.org/D129894

show more ...

[lld-macho] Enable EH frame relocation / pruning

This just removes the code that gates the logic. The main issue here is
perf impact: without {D122258}, LLD takes a significant perf hit because
it n

[lld-macho] Enable EH frame relocation / pruning

This just removes the code that gates the logic. The main issue here is
perf impact: without {D122258}, LLD takes a significant perf hit because
it now has to do a lot more work in the input parsing phase. But with
that change to eliminate unnecessary EH frames from input object files,
the perf overhead here is minimal. Concretely, here are the numbers for
some builds as measured on my 16-core Mac Pro:

**chromium_framework**

This is without the use of `-femit-dwarf-unwind=no-compact-unwind`:

base diff difference (95% CI)
sys_time 1.826 ± 0.019 1.962 ± 0.034 [ +6.5% .. +8.4%]
user_time 9.306 ± 0.054 9.926 ± 0.082 [ +6.2% .. +7.1%]
wall_time 8.225 ± 0.068 8.947 ± 0.128 [ +8.0% .. +9.6%]
samples 15 22

With that flag enabled, the regression mostly disappears, as hoped:

base diff difference (95% CI)
sys_time 1.839 ± 0.062 1.866 ± 0.068 [ -0.9% .. +3.8%]
user_time 9.452 ± 0.068 9.490 ± 0.067 [ -0.1% .. +0.9%]
wall_time 8.383 ± 0.127 8.452 ± 0.114 [ -0.1% .. +1.8%]
samples 17 21

**Unnamed internal app**

Without `-femit-dwarf-unwind`, this is the perf hit:

base diff difference (95% CI)
sys_time 1.372 ± 0.029 1.317 ± 0.024 [ -4.6% .. -3.5%]
user_time 2.835 ± 0.028 2.980 ± 0.027 [ +4.8% .. +5.4%]
wall_time 3.205 ± 0.079 3.383 ± 0.066 [ +4.9% .. +6.2%]
samples 102 83

With `-femit-dwarf-unwind`, the perf hit almost disappears:

base diff difference (95% CI)
sys_time 1.274 ± 0.026 1.270 ± 0.025 [ -0.9% .. +0.3%]
user_time 2.812 ± 0.023 2.822 ± 0.035 [ +0.1% .. +0.7%]
wall_time 3.166 ± 0.047 3.174 ± 0.059 [ -0.2% .. +0.7%]
samples 95 97

Just for fun, I measured the impact of `-femit-dwarf-unwind` on ld64
(`base` has the extra DWARF unwind info in the input object files,
`diff` doesn't):

base diff difference (95% CI)
sys_time 1.128 ± 0.010 1.124 ± 0.023 [ -1.3% .. +0.6%]
user_time 7.176 ± 0.030 7.106 ± 0.094 [ -1.5% .. -0.4%]
wall_time 7.874 ± 0.041 7.795 ± 0.121 [ -1.7% .. -0.3%]
samples 16 25

And for LLD:

base diff difference (95% CI)
sys_time 1.315 ± 0.019 1.280 ± 0.019 [ -3.2% .. -2.0%]
user_time 2.980 ± 0.022 2.822 ± 0.016 [ -5.5% .. -5.0%]
wall_time 3.369 ± 0.038 3.175 ± 0.033 [ -6.2% .. -5.3%]
samples 47 47

So parsing the extra EH frames is a lot more expensive for us than for
ld64. But given that we are quite a lot faster than ld64 to begin with,
I guess this isn't entirely unexpected...

Reviewed By: #lld-macho, oontvoo

Differential Revision: https://reviews.llvm.org/D129540

show more ...

[lld-macho] Accept dylibs with LC_DYLD_EXPORTS_TRIE

This load command specifies the offset and size of the exports trie.
This information used to be a field in LC_DYLD_INFO, but in newer
libraries,

[lld-macho] Accept dylibs with LC_DYLD_EXPORTS_TRIE

This load command specifies the offset and size of the exports trie.
This information used to be a field in LC_DYLD_INFO, but in newer
libraries, it has a dedicated load command: LC_DYLD_EXPORTS_TRIE.

The format of the trie is the same for both load commands, so the code
for parsing it can be shared.

LLD does not generate this yet; it is mainly useful when chained fixups
are in use, as the other members of LC_DYLD_INFO are unused then, so the
smaller LC_DYLD_EXPORTS_TRIE can be output instead.

LLDB gained support for this in D107673.

Fixes #54550

Differential Revision: https://reviews.llvm.org/D129430

show more ...

[lld-macho] Initial support for Linker Optimization Hints

Linker optimization hints mark a sequence of instructions used for
synthesizing an address, like ADRP+ADD. If the referenced symbol ends up

[lld-macho] Initial support for Linker Optimization Hints

Linker optimization hints mark a sequence of instructions used for
synthesizing an address, like ADRP+ADD. If the referenced symbol ends up
close enough, it can be replaced by a faster sequence of instructions
like ADR+NOP.

This commit adds support for 2 of the 7 defined ARM64 optimization
hints:
- LOH_ARM64_ADRP_ADD, which transforms a pair of ADRP+ADD into ADR+NOP
if the referenced address is within +/- 1 MiB
- LOH_ARM64_ADRP_ADRP, which transforms two ADRP instructions into
ADR+NOP if they reference the same page

These two kinds already cover more than 50% of all LOHs in
chromium_framework.

Differential Review: https://reviews.llvm.org/D128093

show more ...

Reland "[lld-macho] Show source information for undefined references"

The error used to look like this:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _baz+0x4

Reland "[lld-macho] Show source information for undefined references"

The error used to look like this:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _baz+0x4)

If DWARF line information is available, we now show where in the source
the references are coming from:

ld64.lld: error: unreferenced symbol: _foo
>>> referenced by: bar.cpp:42 (/path/to/bar.cpp:42)
>>> /path/to/bar.o:(symbol _baz+0x4)

The reland is identical to the first time this landed. The fix was in D128294.
This reverts commit 0cc7ad417585b3185c32e395cc5e6cf082a347af.

Differential Revision: https://reviews.llvm.org/D128184

show more ...

[ADT] [lld-macho] Check for end iterator deref in filter_iterator_base

If ld64.lld was supplied an object file that had a `__debug_abbrev` or
`__debug_str` section, but didn't have any compile unit

[ADT] [lld-macho] Check for end iterator deref in filter_iterator_base

If ld64.lld was supplied an object file that had a `__debug_abbrev` or
`__debug_str` section, but didn't have any compile unit DIEs in
`__debug_info`, it would dereference an iterator pointing to the empty
array of DIEs. This underlying issue started causing segmentation faults
when parsing for `__debug_info` was addded in D128184. That commit was
reverted, and this one fixes the invalid dereference to allow relanding
it.

This commit adds an assertion to `filter_iterator_base`'s dereference
operators to catch bugs like this one.

Ran check-llvm, check-clang and check-lld.

Differential Revision: https://reviews.llvm.org/D128294

show more ...

Revert "[lld-macho] Show source information for undefined references"

This reverts commit cd7624f15369f0d395c1edee1a0b9592083d2fe0.
See https://reviews.llvm.org/D128184#3597534

[lld-macho] Show source information for undefined references

The error used to look like this:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _baz+0x4)

If DWA

[lld-macho] Show source information for undefined references

The error used to look like this:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _baz+0x4)

If DWARF line information is available, we now show where in the source
the references are coming from:

ld64.lld: error: unreferenced symbol: _foo
>>> referenced by: bar.cpp:42 (/path/to/bar.cpp:42)
>>> /path/to/bar.o:(symbol _baz+0x4)

Differential Revision: https://reviews.llvm.org/D128184

show more ...

[lld-macho][reland] Support EH frames under arm64

This reverts commit 10641a42e2286679e0d36ca827e1a40d95ae8ef1.

Differential Revision: https://reviews.llvm.org/D124561

[lld-macho][reland] Initial support for EH Frames

This reverts commit 942f4e3a7cc9a9f8b2654817cff12907d1276031.

The additional change required to avoid the assertion errors seen
previously is:

-

[lld-macho][reland] Initial support for EH Frames

This reverts commit 942f4e3a7cc9a9f8b2654817cff12907d1276031.

The additional change required to avoid the assertion errors seen
previously is:

--- a/lld/MachO/ICF.cpp
+++ b/lld/MachO/ICF.cpp
@@ -443,7 +443,9 @@ void macho::foldIdenticalSections() {
/*relocVA=*/0);
isec->data = copy;
}
- } else {
+ } else if (!isEhFrameSection(isec)) {
+ // EH frames are gathered as hashables from unwindEntry above; give a
+ // unique ID to everything else.
isec->icfEqClass[0] = ++icfUniqueID;
}
}

Differential Revision: https://reviews.llvm.org/D123435

show more ...

Revert "[lld-macho] Initial support for EH Frames"

This reverts commit 826be330af9c0a8553a5b32718ecd2d97e10438e.

This was causing a test failure on build bots:
- https://lab.llvm.org/buildbot/#/b

Revert "[lld-macho] Initial support for EH Frames"

This reverts commit 826be330af9c0a8553a5b32718ecd2d97e10438e.

This was causing a test failure on build bots:
- https://lab.llvm.org/buildbot/#/builders/36/builds/21770
- https://lab.llvm.org/buildbot/#/builders/58/builds/23913

show more ...

Revert "[lld-macho] Support EH frames under arm64"

This reverts commit 977d62c33e3343a394777c1754682761eebb66cd.

This change was causing crashes in 2 tests on the buildbots:
- https://lab.llvm.or

Revert "[lld-macho] Support EH frames under arm64"

This reverts commit 977d62c33e3343a394777c1754682761eebb66cd.

This change was causing crashes in 2 tests on the buildbots:
- https://lab.llvm.org/buildbot/#/builders/58/builds/23914
- https://lab.llvm.org/buildbot/#/builders/36/builds/21771

show more ...