This is an archive of the discontinued LLVM Phabricator instance.

[lld/mac] Don't load DylibFiles from the DylibFile constructor
ClosedPublic

Authored by thakis on May 31 2021, 12:04 PM.

Details

Summary

loadDylib() keeps a name->DylibFile cache, but it only writes
to the cache once the DylibFile constructor has completed.
So dylib loads done recursively from the DylibFile constructor
wouldn't use the cache.

Now, we load additional dylibs after writing to the cache,
which means the cache now gets used for dylibs loaded because
they're referenced from other dylibs.

Related to PR49514 and PR50101, but no dramatic behavior change in itself.
(Technically we no longer crash when a tbd file reexports itself,
but that doesn't happen in practice. We now accept it silently instead
of crashing; ld64 has a diag for the reexport cycle.)

Diff Detail

Event Timeline

thakis created this revision.May 31 2021, 12:04 PM
Herald added a reviewer: gkm. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
thakis requested review of this revision.May 31 2021, 12:04 PM
thakis updated this revision to Diff 348852.May 31 2021, 12:27 PM

clang-format

tschuett added inline comments.
lld/MachO/DriverUtils.cpp
204

Do you really the cute & hack? Can't you always do loadedLibs[Path] = file;

thakis added inline comments.May 31 2021, 3:19 PM
lld/MachO/DriverUtils.cpp
204

It's the canonical way to write a caching function. So my thinking was we need to have a comment about this so that nobody changes this to using a reference naively, and if we have to add the comment anyways we might as well take what the comment pays for. But I don't feel terribly strongly about it.

int3 accepted this revision.Jun 1 2021, 11:25 AM

lgtm

This revision is now accepted and ready to land.Jun 1 2021, 11:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 1 2021, 12:31 PM