[PATCH] D103488: [lld/mac] Emit only one LC_LOAD_DYLIB per dylib

[Nico Weber via Phabricator via llvm-commits]

thakis created this revision.
thakis added a reviewer: lld-macho.
Herald added a reviewer: int3.
Herald added a reviewer: gkm.
Herald added a project: lld-macho.
thakis requested review of this revision.

In some cases, we end up with several distinct DylibFiles that
have the same install name. Only emit a single LC_LOAD_DYLIB in
those cases.

This happens in 3 cases I know of:

1. Some tbd files are symlinks. libpthread.tbd is a symlink against libSystem.tbd for example, so `-lSystem -lpthread` loads libSystem.tbd twice. We could (and maybe should) cache loaded dylibs by realpath() to catch this.

2. Some tbd files are copies of each other. For example, CFNetwork.framework/CFNetwork.tbd and CFNetwork.framework/Versions/A/CFNetwork.tbd are two distinct copies of the same file. The former is found by `-framework CFNetwork` and the latter by the reexport in CoreServices.tbd. We could conceivably catch this by making `-framework` search look in `Versions/Current` instead of in the root, and/or by using a content hash to cache tbd files, but that's starting to sound complicated.

3. Magic $ld$ symbol processing can change the install name of a dylib based on the target platform_version. Here, two truly distinct dylibs can have the same install name.

So we need this code to deal with (3) anyways. Might as well use
it for 1 and 2, at least for now :)

With this (and D103430 <https://reviews.llvm.org/D103430>), clang-format links in the same dylibs
when linked with lld and ld64.


https://reviews.llvm.org/D103488

Files:
  lld/MachO/Writer.cpp
  lld/test/MachO/dylink-ordinal.s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D103488.349077.patch
Type: text/x-patch
Size: 3951 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210601/8d2ff0fa/attachment.bin>