[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

[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

(cherry picked from commit 241f0e8b76d544a4a07a7f775b8421632539be19)

show more ...

Reland "[lld-macho] Implement -load_hidden"

This flag was introduced in ld64-609. It instructs the linker to link to
a static library while treating its symbols as if they had hidden
visibility. Thi

Reland "[lld-macho] Implement -load_hidden"

This flag was introduced in ld64-609. It instructs the linker to link to
a static library while treating its symbols as if they had hidden
visibility. This is useful when building a dylib that links to static
libraries but we don't want the symbols from those to be exported.

Closes #51505

This reland adds bitcode file handling, so we won't get any compile
errors due to BitcodeFile::forceHidden being unused.

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

show more ...

Revert "[lld-macho] Implement -load_hidden"

This reverts commit 4c79e1a3f4eb790f40239833ae237e828ce07386.

Broke this bot: https://lab.llvm.org/buildbot/#builders/57/builds/20319

[lld-macho] Implement -load_hidden

This flag was introduced in ld64-609. It instructs the linker to link to
a static library while treating its symbols as if they had hidden
visibility. This is usef

[lld-macho] Implement -load_hidden

This flag was introduced in ld64-609. It instructs the linker to link to
a static library while treating its symbols as if they had hidden
visibility. This is useful when building a dylib that links to static
libraries but we don't want the symbols from those to be exported.

Closes #51505

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

show more ...

[lld-macho] Add support for -w

This flag suppresses warnings produced by the linker. In ld64 this has
an interesting interaction with -fatal_warnings, it silences the
warnings but the link still fai

[lld-macho] Add support for -w

This flag suppresses warnings produced by the linker. In ld64 this has
an interesting interaction with -fatal_warnings, it silences the
warnings but the link still fails. Instead of doing that here we still
print the warning and eagerly fail the link in case both are passed,
this seems more reasonable so users can understand why the link fails.

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

show more ...

[lld/mac] For catalyst outputs, tolerate implicitly linking against mac-only tbd files

Before this,

clang empty.cc -target x86_64-apple-ios13.1-macabi \
-framework CoreServices -fuse-ld=lld

[lld/mac] For catalyst outputs, tolerate implicitly linking against mac-only tbd files

Before this,

clang empty.cc -target x86_64-apple-ios13.1-macabi \
-framework CoreServices -fuse-ld=lld

would error out with

ld64.lld: error: path/to/MacOSX.sdk/System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/
Versions/A/CarbonCore.tbd(
/System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/
Versions/A/CarbonCore) is incompatible with x86_64 (macCatalyst)

Now it works, like with ld64.

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

show more ...

Re-land [LLD] Remove global state in lldCommon

Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers wi

Re-land [LLD] Remove global state in lldCommon

Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inherit from this structure and add their own global state, in the same way as for the existing COFFLinkerContext.

See discussion in https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html

The previous land f860fe362282ed69b9d4503a20e5d20b9a041189 caused issues in https://lab.llvm.org/buildbot/#/builders/123/builds/8383, fixed by 22ee510dac9440a74b2e5b3fe3ff13ccdbf55af3.

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

show more ...

Revert [LLD] Remove global state in lldCommon

It seems to be causing issues on https://lab.llvm.org/buildbot/#/builders/123/builds/8383

[LLD] Remove global state in lldCommon

Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inher

[LLD] Remove global state in lldCommon

Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inherit from this structure and add their own global state, in the same way as for the existing COFFLinkerContext.

See discussion in https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html

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

show more ...

[MachO] Properly reset global state

We need to reset global state between runs, similar to the other ports.
There's some file-static state which needs to be reset as well and we
need to add some new

[MachO] Properly reset global state

We need to reset global state between runs, similar to the other ports.
There's some file-static state which needs to be reset as well and we
need to add some new helpers for that.

With this change, most LLD Mach-O tests pass with `LLD_IN_TEST=2` (which
runs the linker twice on each test). Some tests will be fixed by the
remainder of this stack, and the rest are fundamentally incompatible
with that mode (e.g. they intentionally throw fatal errors).

Fixes PR52070.

Reviewed By: #lld-macho, int3

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

show more ...

[lld-macho] Fix dangling string reference when adding frameworks

In Driver.cpp, addFramework used std::string instance to represent the path of a framework, which will be freed after the function re

[lld-macho] Fix dangling string reference when adding frameworks

In Driver.cpp, addFramework used std::string instance to represent the path of a framework, which will be freed after the function returns. However, this string is stored in loadedArchive, which will be used later to compare with path of newly added frameworks. This caused https://bugs.llvm.org/show_bug.cgi?id=52133. A test is included in this commit to reproduce this bug.

Now resolveDylibPath returns a StringRef instance, and it uses StringSaver to save its data, then returns it to functions on the top. This ensures the resolved framework path is still valid after LC_LINKER_OPTION is parsed.

Reviewed By: int3, #lld-macho, oontvoo

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

show more ...

[lld/mac] Search .tbd before binary for framework files too

This matters for example for the iPhoneSimulator14.0.sdk, which has
a System/Library/Frameworks/UIKit.framework/UIKit that has
LC_BUILD_VE

[lld/mac] Search .tbd before binary for framework files too

This matters for example for the iPhoneSimulator14.0.sdk, which has
a System/Library/Frameworks/UIKit.framework/UIKit that has
LC_BUILD_VERSION with minos of 14.0, so linking against that file
will produce warnings like:

.../iPhoneSimulator14.0.sdk/System/Library/Frameworks/UIKit.framework/UIKit
has version 14.0.0, which is newer than target minimum of 12.0.0

when targeting x86_64-apple-ios12.0-simulator. That doens't happen when
linking against UIKit.tbd instead, obviously.

Linking with RC_TRACE_DYLIB_SEARCHING=1 shows that ld64 also searches
the tbd file first, and we already get that right for non-framework
dylibs.

Fixes crbug.com/1249456.

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

show more ...

[lld-macho] Refactor archive loading

The previous logic was duplicated between symbol-initiated
archive loads versus flag-initiated loads (i.e. `-force_load` and
`-ObjC`). This resulted in code dupl

[lld-macho] Refactor archive loading

The previous logic was duplicated between symbol-initiated
archive loads versus flag-initiated loads (i.e. `-force_load` and
`-ObjC`). This resulted in code duplication as well as redundant work --
we would create Archive instances twice whenever we had one of those
flags; once in `getArchiveMembers` and again when we constructed the
ArchiveFile.

This was motivated by an upcoming diff where we load archive members
containing ObjC-related symbols before loading those containing
ObjC-related sections, as well as before performing symbol resolution.
Without this refactor, it would be difficult to do that while avoiding
loading the same archive member twice.

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

show more ...

[lld-macho] Disambiguate bitcode files with the same name by archive name/offset in archive

Ported from COFF/ELF; test is adapted from
test/COFF/thinlto-archivecollision.ll

LTO expects every bitcod

[lld-macho] Disambiguate bitcode files with the same name by archive name/offset in archive

Ported from COFF/ELF; test is adapted from
test/COFF/thinlto-archivecollision.ll

LTO expects every bitcode file to have a unique name. If given multiple bitcode
files with the same name, it errors with "Expected at most one ThinLTO module
per bitcode file".

This change incorporates the archive name, to disambiguate members with the
same name in different archives and the offset in archive to disambiguate
members with the same name in the same archive.

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

show more ...

[lld-macho][nfc] Remove unnecessary llvm:: namespace prefixes

[OptTable] Rename PrintHelp to printHelp

To be consistent with other member functions and match the coding standard.

Revert "[lld-macho] Have path-related functions return std::string, not StringRef"

This reverts commit 1d31fb8d122b1117cf20a9edc09812db8472e930.

Making `rerootPath` return a temporary std::string c

Revert "[lld-macho] Have path-related functions return std::string, not StringRef"

This reverts commit 1d31fb8d122b1117cf20a9edc09812db8472e930.

Making `rerootPath` return a temporary std::string caused a
use-after-free:

https://ci.chromium.org/ui/p/chromium/builders/try/win_upload_clang/1608/overview

show more ...

[lld-macho] Have path-related functions return std::string, not StringRef

findLibrary() returned a StringRef while findFramework & other helper
functions returned std::strings. Standardize on std::s

[lld-macho] Have path-related functions return std::string, not StringRef

findLibrary() returned a StringRef while findFramework & other helper
functions returned std::strings. Standardize on std::string.

(I initially tried making the helper functions all return StringRefs,
but I realized we shouldn't return input StringRefs since their
lifetimes would not be obvious from the calling code.)

show more ...

[lld/mac] Print dylib search details with --print-dylib-search or RC_TRACE_DYLIB_SEARCHING

For debugging dylib loading, it's useful to have some insight into what
the linker is doing.

ld64 has the

[lld/mac] Print dylib search details with --print-dylib-search or RC_TRACE_DYLIB_SEARCHING

For debugging dylib loading, it's useful to have some insight into what
the linker is doing.

ld64 has the undocumented RC_TRACE_DYLIB_SEARCHING env var
for this printing dylib search candidates.

This adds a flag --print-dylib-search to make lld print the seame information.
It's useful for users, but also for writing tests. The output is formatted
slightly differently than ld64, but we still support RC_TRACE_DYLIB_SEARCHING
to offer at least a compatible way to trigger this.

ld64 has both `-print_statistics` and `-trace_symbol_output` to enable
diagnostics output. I went with "print" since that seems like a more
straightforward name.

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

show more ...

[lld/mac] Implement support for searching dylibs with @rpath/ in install name

Also adjust a few comments, and move the DylibFile comment talking about
umbrella next to the parameter again.

Differen

[lld/mac] Implement support for searching dylibs with @rpath/ in install name

Also adjust a few comments, and move the DylibFile comment talking about
umbrella next to the parameter again.

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

show more ...

[lld-macho] Parse re-exports of nested TAPI documents

D103423 neglected to call `parseReexports()` for nested TBD
documents, leading to symbol resolution failures when trying to look up
a symbol nes

[lld-macho] Parse re-exports of nested TAPI documents

D103423 neglected to call `parseReexports()` for nested TBD
documents, leading to symbol resolution failures when trying to look up
a symbol nested more than one level deep in a TBD file. This fixes the
regression and adds a test.

It also appears that `umbrella` wasn't being set properly when calling
`parseLoadCommands` -- it's supposed to resolve to `this` if `nullptr`
is passed. I didn't write a failing test case for this but I've made
`umbrella` a member so the previous behavior should be preserved.

Reviewed By: #lld-macho, thakis

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

show more ...

[lld/mac] Address review feedback and improve a comment

I forgot to move the message() call around as requested in D103428
before committing that change. Move it now.

Also, improve the ordinal uniq

[lld/mac] Address review feedback and improve a comment

I forgot to move the message() call around as requested in D103428
before committing that change. Move it now.

Also, improve the ordinal uniq'ing comment. I hadn't realized that the
distinct-but-identical files happen with --reproduce and not in general.

No behavior change.

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

show more ...

[lld/mac] Make -t work correctly with -flat_namespace

We used to not print dylibs referenced by other dylibs in `-t` mode. This
affected reexports, and with `-flat_namespace` also just dylibs loaded

[lld/mac] Make -t work correctly with -flat_namespace

We used to not print dylibs referenced by other dylibs in `-t` mode. This
affected reexports, and with `-flat_namespace` also just dylibs loaded by
dylibs. Now we print them.

Fixes PR49514.

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

show more ...

[lld-macho][nfc] Remove unnecessary use of Optional<T*>

In all of these cases, the functions could simply return a nullptr instead of {}.
There is no case where Optional<nullptr> has a special meani

[lld-macho][nfc] Remove unnecessary use of Optional<T*>

In all of these cases, the functions could simply return a nullptr instead of {}.
There is no case where Optional<nullptr> has a special meaning.

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

show more ...

[lld/mac] fix test failure after 24979e111

If there is an error reading the dylib, we shouldn't try
to load its reexports.

Caught e.g. by https://lab.llvm.org/buildbot/#/builders/36/builds/8946