[all-commits] [llvm/llvm-project] 2e8e1b: [lld-macho] Support linking against stub dylibs

[Jez Ng via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 2e8e1bdb89392f8bbe1c3886b1f8da8746659bb2
      https://github.com/llvm/llvm-project/commit/2e8e1bdb89392f8bbe1c3886b1f8da8746659bb2
  Author: Jez Ng <jezng at fb.com>
  Date:   2020-11-10 (Tue, 10 Nov 2020)

  Changed paths:
    M lld/MachO/Driver.cpp
    A lld/test/MachO/dylib-stub.yaml

  Log Message:
  -----------
  [lld-macho] Support linking against stub dylibs

Stub dylibs differ from "real" dylibs in that they lack any content in
their sections. What they do have are export tries and symbol tables,
which means we can still link against them. I am unclear how to
properly create these stub dylibs; XCode 11.3's `lipo` is able to create
stub dylibs, but those lack LC_ID_DYLIB load commands and are considered
invalid by most tooling. Newer versions of `lipo` aren't able to create
stub dylibs at all.  However, recent SDKs in XCode still come with valid
stub dylibs, so it still seems worthwhile to support them. The YAML in
this diff's test was generated by taking a non-stub dylib and editing
the appropriate fields.

Reviewed By: #lld-macho, smeenai

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


  Commit: b86908171ea81a57f11fb29960328f57aaa9e7f9
      https://github.com/llvm/llvm-project/commit/b86908171ea81a57f11fb29960328f57aaa9e7f9
  Author: Jez Ng <jezng at fb.com>
  Date:   2020-11-10 (Tue, 10 Nov 2020)

  Changed paths:
    M lld/MachO/Writer.cpp
    M lld/test/MachO/headerpad.s
    M lld/test/MachO/load-commands.s
    M lld/test/MachO/local-got.s
    M lld/test/MachO/relocations.s

  Log Message:
  -----------
  [lld-macho] Implement LC_UUID

Apple devtools use this to locate the dSYM files for a given
binary.

The UUID is computed based on an MD5 hash of the binary's contents. In order to
hash the contents, we must first write them, but LC_UUID itself must be part of
the written contents in order for all the offsets to be calculated correctly.
We resolve this circular paradox by first writing an LC_UUID with an all-zero
UUID, then updating the UUID with its real value later.

I'm not sure there's a good way to test that the value of the UUID is
"as expected", so I've just checked that it's present.

Reviewed By: #lld-macho, compnerd, smeenai

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


  Commit: 6cf244327b0da1f0b5c40015dd19d5cb2bdd5e93
      https://github.com/llvm/llvm-project/commit/6cf244327b0da1f0b5c40015dd19d5cb2bdd5e93
  Author: Jez Ng <jezng at fb.com>
  Date:   2020-11-10 (Tue, 10 Nov 2020)

  Changed paths:
    M lld/MachO/OutputSegment.cpp
    M lld/test/MachO/segments.s

  Log Message:
  -----------
  [lld-macho][easy] Fix segment max protection

We should have maxprot == initprot for all non-i386 architectures, which
is what ld64 does.

Reviewed By: #lld-macho, compnerd

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


  Commit: 21f831134c90671bd720533c1f46b88b6979300f
      https://github.com/llvm/llvm-project/commit/21f831134c90671bd720533c1f46b88b6979300f
  Author: Jez Ng <jezng at fb.com>
  Date:   2020-11-10 (Tue, 10 Nov 2020)

  Changed paths:
    M lld/MachO/CMakeLists.txt
    M lld/MachO/Config.h
    M lld/MachO/Driver.cpp
    M lld/MachO/InputFiles.cpp
    M lld/MachO/InputFiles.h
    A lld/MachO/LTO.cpp
    A lld/MachO/LTO.h
    M lld/MachO/Options.td
    A lld/test/MachO/lto-save-temps.ll

  Log Message:
  -----------
  [lld-macho] Add very basic support for LTO

Just enough to consume some bitcode files and link them. There's more
to be done around the symbol resolution API and the LTO config, but I don't yet
understand what all the various LTO settings do...

Reviewed By: #lld-macho, compnerd, smeenai, MaskRay

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


Compare: https://github.com/llvm/llvm-project/compare/703038b35a86...21f831134c90