[lld/mac] Emit only one LC_LOAD_DYLIB per dylib
authorNico Weber <thakis@chromium.org>
Tue, 1 Jun 2021 19:13:46 +0000 (15:13 -0400)
committerNico Weber <thakis@chromium.org>
Tue, 1 Jun 2021 22:15:35 +0000 (18:15 -0400)
commitaeae3e0ba9061a40209987d6256e489146c2bffb
treeb7abcefa7859abe09cb1984668ae789d8ba5e3d2
parentda1db49409657d5212185ab9952ee35d99b773d4
[lld/mac] Emit only one LC_LOAD_DYLIB per dylib

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), clang-format links in the same dylibs
when linked with lld and ld64.

Differential Revision: https://reviews.llvm.org/D103488
lld/MachO/Writer.cpp
lld/test/MachO/dylink-ordinal.s [new file with mode: 0644]