This is an archive of the discontinued LLVM Phabricator instance.

[lld-macho] Fix & fold reexport-nested-libs test into stub-link.s
ClosedPublic

Authored by int3 on Mar 3 2021, 8:44 AM.

Details

Summary

The reexport-nested-libs test added in D97438 was a bit wonky.

First, it was linking against libReexportSystem.tbd which targets the
iOS simulator, and which in turn attempted to re-export the iOS
simulator's libSystem. However, due to the way -syslibroot works, it
was actually re-exporting the macOS libSystem.

As a result, the test was not actually able to resolve the symbols in
the desired libSystem. I'm guessing that @oontvoo was confused by this
and therefore included those symbols in libReexportSystem.tbd itself.
But this means that the test wasn't actually testing the resolution of
re-exported symbols (though it did at least verify that the re-exported
libraries could be located).

After some consideration, I figured that stub-link.s could be extended
to cover what reexport-nested-libs.s was attempting to do. The test
targets macOS, so we only have one -syslibroot and no chance of
confusion.

Diff Detail

Event Timeline

int3 created this revision.Mar 3 2021, 8:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2021, 8:44 AM
int3 requested review of this revision.Mar 3 2021, 8:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2021, 8:44 AM
int3 added a comment.Mar 3 2021, 8:47 AM

I've added a cautionary comment about -syslibroot in D97799: [lld-macho] Require -arch and -platform_version to always be specified. D97867: [lld-macho] Filter TAPI re-exports by target will also help to flag future such issues since we'll now check the platform of the re-exports we are attempting to link against.

lld/test/MachO/Inputs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation.tbd
14

ld64's TAPI parser is more picky than ours, so it doesn't recognize a file as valid TAPI without these dots

oontvoo added inline comments.Mar 3 2021, 9:19 AM
lld/test/MachO/Inputs/libReexportSystem.tbd
8–9

It wasn't able to find the libSystem with .dylib (because it was trying to looking for a .tbd extension.
I'm curious how your change fixed it

oontvoo accepted this revision.Mar 3 2021, 9:32 AM

LGTM (with just one question)

lld/test/MachO/stub-link.s
13

Would the test that use -lReexportSystem (rather than explicitly specifying it as input) follow any different code path?

This revision is now accepted and ready to land.Mar 3 2021, 9:32 AM
int3 added inline comments.Mar 3 2021, 11:54 AM
lld/test/MachO/Inputs/libReexportSystem.tbd
8–9

hmm I'm not sure why it didn't work for you. But if resolveDylibPath doesn't find a file ending in .dylib, it will replace .dylib with .tbd and try to find that.

int3 added inline comments.Mar 3 2021, 11:56 AM
lld/test/MachO/stub-link.s
13

it wouldn't cause findLibrary to be invoked for libReexportSystem, but we have other tests that use -lFoo, so that code path is covered

This revision was landed with ongoing or failed builds.Mar 4 2021, 11:37 AM
This revision was automatically updated to reflect the committed changes.
lld/test/MachO/Inputs/libReexportSystem.tbd