[all-commits] [llvm/llvm-project] aeae3e: [lld/mac] Emit only one LC_LOAD_DYLIB per dylib

[Nico Weber via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: aeae3e0ba9061a40209987d6256e489146c2bffb
      https://github.com/llvm/llvm-project/commit/aeae3e0ba9061a40209987d6256e489146c2bffb
  Author: Nico Weber <thakis at chromium.org>
  Date:   2021-06-01 (Tue, 01 Jun 2021)

  Changed paths:
    M lld/MachO/Writer.cpp
    A lld/test/MachO/dylink-ordinal.s

  Log Message:
  -----------
  [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