[🍒 stable/20240723] DynamicLoaderDarwin load images in parallel with preload

[DmT021]

Cherry-pick llvm#110646

This change enables DynamicLoaderDarwin to load modules in parallel using the thread pool. This new behavior is controlled by a new setting plugin.dynamic-loader.darwin.experimental.enable-parallel-image-load, which is enabled by default. When disabled, DynamicLoaderDarwin will load modules sequentially as before.

[DmT021]

@augusto2112 PTAL

[augusto2112]

@swift-ci test

[augusto2112]

@swift-ci test

[augusto2112]

@DmT021 the test suite failed on test:

FAIL: test_dsym (TestSwiftObjCMainConflictingDylibs.TestSwiftObjCMainConflictingDylibs)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ec2-user/jenkins/workspace/apple-llvm-project-pr-macos/branch-stable/20240723/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1768, in test_method
    return attrvalue(self)
  File "/Users/ec2-user/jenkins/workspace/apple-llvm-project-pr-macos/branch-stable/20240723/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 149, in wrapper
    return func(*args, **kwargs)
  File "/Users/ec2-user/jenkins/workspace/apple-llvm-project-pr-macos/branch-stable/20240723/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 149, in wrapper
    return func(*args, **kwargs)
  File "/Users/ec2-user/jenkins/workspace/apple-llvm-project-pr-macos/branch-stable/20240723/llvm-project/lldb/test/API/lang/swift/clangimporter/objcmain_conflicting_dylibs/TestSwiftObjCMainConflictingDylibs.py", line 39, in test
    self.expect("fr var baz", "correct baz", substrs=["i_am_from_Foo"])
  File "/Users/ec2-user/jenkins/workspace/apple-llvm-project-pr-macos/branch-stable/20240723/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2474, in expect
    self.fail(log_msg)
AssertionError: Ran command:
"fr var baz"

Got output:
(Baz) baz = {
  i_am_from_Bar = 23
}

Expecting sub string: "i_am_from_Foo" (was not found)
correct baz

I wonder if this could be a race condition? I'm going to rerun the test suite, but perhaps you could run this test locally on a loop to see if any run fails?

[augusto2112]

@swift-ci test macOS

[DmT021]

Yeah, I'm checking it.

EDIT: I can confirm there's a race condition somewhere. Will dig into it now.

[DmT021]

@augusto2112 The issue is that this test depends on the order of loading the dylibs. It depends on:

1. the order of their appearance in the main executable.

otool -L /Users/dmt021/w/swift-project/build/Ninja-RelWithDebInfoAssert/lldb-macosx-arm64/lldb-test-build.noindex/lang/swift/clangimporter/objcmain_conflicting_dylibs/TestSwiftObjCMainConflictingDylibs.test_dwarf/a.out
/Users/dmt021/w/swift-project/build/Ninja-RelWithDebInfoAssert/lldb-macosx-arm64/lldb-test-build.noindex/lang/swift/clangimporter/objcmain_conflicting_dylibs/TestSwiftObjCMainConflictingDylibs.test_dwarf/a.out:
  @executable_path/libFoo.dylib (compatibility version 0.0.0, current version 0.0.0)
  @executable_path/libBar.dylib (compatibility version 0.0.0, current version 0.0.0)

2. The order in which we add the modules in Target::GetOrCreateModule. When we load the modules in parallel, their order is random. That's why this test is flaky.

The issue can be reproduced without the patch if you swap -lFoo -lBar in lldb/test/API/lang/swift/clangimporter/objcmain_conflicting_dylibs/Makefile. When libBar is in front of libFoo LLDB will always resolve Buz incorrectly.

You can also see later in the tests we expect fr var baz in the context of Bar.swift to be resolved incorrectly:

        # This is failing because the Target-SwiftASTContext uses the
        # amalgamated target header search options from all dylibs.
        self.expect("expression baz", "wrong baz", substrs=["i_am_from_Foo"])
        self.expect("fr var baz", "wrong baz", substrs=["i_am_from_Foo"])

I think the best solution would be to fix this dependency on the order of modules in the ModuleList but not sure how difficult that would be.

[augusto2112]

@augusto2112 The issue is that this test depends on the order of loading the dylibs. It depends on:

1. the order of their appearance in the main executable.

otool -L /Users/dmt021/w/swift-project/build/Ninja-RelWithDebInfoAssert/lldb-macosx-arm64/lldb-test-build.noindex/lang/swift/clangimporter/objcmain_conflicting_dylibs/TestSwiftObjCMainConflictingDylibs.test_dwarf/a.out
/Users/dmt021/w/swift-project/build/Ninja-RelWithDebInfoAssert/lldb-macosx-arm64/lldb-test-build.noindex/lang/swift/clangimporter/objcmain_conflicting_dylibs/TestSwiftObjCMainConflictingDylibs.test_dwarf/a.out:
  @executable_path/libFoo.dylib (compatibility version 0.0.0, current version 0.0.0)
  @executable_path/libBar.dylib (compatibility version 0.0.0, current version 0.0.0)

2. The order in which we add the modules in Target::GetOrCreateModule. When we load the modules in parallel, their order is random. That's why this test is flaky.

The issue can be reproduced without the patch if you swap -lFoo -lBar in lldb/test/API/lang/swift/clangimporter/objcmain_conflicting_dylibs/Makefile. When libBar is in front of libFoo LLDB will always resolve Buz incorrectly.

You can also see later in the tests we expect fr var baz in the context of Bar.swift to be resolved incorrectly:

        # This is failing because the Target-SwiftASTContext uses the
        # amalgamated target header search options from all dylibs.
        self.expect("expression baz", "wrong baz", substrs=["i_am_from_Foo"])
        self.expect("fr var baz", "wrong baz", substrs=["i_am_from_Foo"])

I think the best solution would be to fix this dependency on the order of modules in the ModuleList but not sure how difficult that would be.

Besides the first binary, which should be the executable in the module list, the order of all the other binaries shouldn't matter. Also we probably should remove this test now that we no longer have a global scratch context.

Would you mind adding a new commit on top of the current one removing that test?

[DmT021]

Sure

[DmT021]

@augusto2112 rerun the tests, please

[augusto2112]

@swift-ci test

[DmT021]

@augusto2112 thank you!