[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