[all-commits] [llvm/llvm-project] 241f0e: [lld/mac] Add support for $ld$previous symbols wit...

Nico Weber via All-commits all-commits at lists.llvm.org
Thu Jul 28 17:37:39 PDT 2022


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 241f0e8b76d544a4a07a7f775b8421632539be19
      https://github.com/llvm/llvm-project/commit/241f0e8b76d544a4a07a7f775b8421632539be19
  Author: Nico Weber <thakis at chromium.org>
  Date:   2022-07-28 (Thu, 28 Jul 2022)

  Changed paths:
    M lld/MachO/DriverUtils.cpp
    M lld/MachO/InputFiles.cpp
    M lld/MachO/InputFiles.h
    M lld/MachO/Writer.cpp
    M lld/test/MachO/special-symbol-ld-previous.s

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




More information about the All-commits mailing list