🍒 Cherrypicks to allow Swift to enable LLDB tests in Windows builds #9429
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This argument allows to specify the path to make which is used by LLDB API tests to compile test programs. It might come in handy for setting up cross-platform remote runs of API tests on Windows host. It can be used to override the make path of LLDB API tests using `LLDB_TEST_USER_ARGS` argument: ``` cmake ... -DLLDB_TEST_USER_ARGS="...;--make;C:\\Path\\to\\make.exe;..." ... ```
On Windows the function does not have a symbol associated with it:
Function: id = {0x000001c9}, name = "_Dfunction", range =
[0x0000000140001000-0x0000000140001004)
LineEntry: <...>
Whereas it does on Linux:
Function: id = {0x00000023}, name = "_Dfunction", range =
[0x0000000000000734-0x0000000000000738)
LineEntry: <...>
Symbol: id = {0x00000058}, range =
[0x0000000000000734-0x0000000000000738), name="_Dfunction"
This means that frame.symbol is not valid on Windows.
However, frame.function is valid and it also has a "mangled" attribute.
So I've updated the test to check the symbol if we've got it, and the
function always.
In both cases we check that mangled is empty (meaning it has not been
treated as mangled) and that the display name matches the original
symbol name.
) The goal here is to remove the third_party/Python/module tree, which LLDB tests only use to `import pexpect`. This package is available on `pip`, and I believe should not be hard to obtain. However, in case it isn't easily available, deleting the tree right now could cause disruption. This introduces a `LLDB_TEST_USE_VENDOR_PACKAGES` cmake param that can be enabled, and the tests will continue loading that tree. By default, it is enabled, meaning there's really no change here. A followup change will disable it by default once all known build bots are updated to include this package. When disabled, an eager cmake check runs that makes sure `pexpect` is available before waiting for the test to fail in an obscure way. Later, this option will go away, and when it does, we can delete the tree too. Ideally this is not disruptive, and we can remove it in a week or two.
If you run cmake without pexpect installed it errors as expected. However, if you just `pip install pexpect` and cmake again it still doesn't find it because it cached the result of the search. Unset the result before looking for pexpect. So that this works as expected: cmake ... pip3 install pexpect cmake ...
This executed Alex' idea [1] of adding pexpect to the list of "strict test requirements" as we're planning to stop vendoring it. This will ensure all the bots have the package before we toggle the default. [1] llvm#83191
…T_TEST_REQUIREMENTS See llvm#22648 for why we don't use it on Windows. Any pexpect tests are skipped there.
…Z7 (llvm#106686) This fixes a regression from f58330c. That commit changed the clang-cl options /Zi and /Z7 to be implemented as aliases of -g rather than having separate handling. This had the unintended effect, that when assembling .s files with clang-cl, the /Z7 option (which implies using CodeView debug info) was treated as a -g option, which causes `ClangAs::ConstructJob` to pick up the option as part of `Args.getLastArg(options::OPT_g_Group)`, which sets the `WantDebug` variable. Within `Clang::ConstructJob`, we check for whether explicit `-gdwarf` or `-gcodeview` options have been set, and if not, we pick the default debug format for the current toolchain. However, in `ClangAs`, if debug info has been enabled, it always adds DWARF debug info. Add similar logic in `ClangAs` - check if the user has explicitly requested either DWARF or CodeView, otherwise look up the toolchain default. If we (either implicitly or explicitly) should be producing CodeView, don't enable the default `ClangAs` DWARF generation. This fixes the issue, where assembling a single `.s` file with clang-cl, with the /Z7 option, causes the file to contain some DWARF sections. This causes the output executable to contain DWARF, in addition to the separate intended main PDB file. By having the output executable contain DWARF sections, LLDB only looks at the (very little) DWARF info in the executable, rather than looking for a separate standalone PDB file. This caused an issue with LLDB's tests, llvm#101710.
…lvm#111729) Use SEND_ERROR (continue processing, but skip generation) instead of FATAL_ERROR (stop processing and generation). This means that developers get to see all errors at once, instead of seeing just the first error and having to reconfigure to discover the next one.
…m#111747) This module is used in various helper scripts since llvm#93712
Many LLDB's dotest.py based tests require the `make` tool. If it's not found in Path, they fail with an obscure error and show up as `UNRESOLVED`. On Windows, llvm-lit takes care of MSYS based testing tools like cat, printf, etc., but `make` is not part of that. Let's catch the situation early and check for it at configuration time. This error isn't fatal: It should fail the build, but not immediately stop the configuration process. There might be other issues further down the line that can be caught in the same buildbot run.
…m#112342) In recent PR llvm#111531 for Windows support, we enabled tests that require the `make` tool. On Windows, default install directories likely contain spaces, in this case e.g. `C:\Program Files (x86)\GnuWin32\bin\make.exe`. It's typically handled well by CMake, so that today invocations from `dotest.py` don't cause issues. However, we also have nested invocations from a number of Makefiles themselves. These still failed if the path to the `make` tool contains spaces. This patch attempts to fix the functionalities/completion test by adding quotes in the respective Makefile. If it keeps passing on the bots, we can roll out the fix to all affected tests.
…m#112360) Following up from llvm#112342, we roll out the fix and quote nested `make` invocations in all API tests.
weliveindetail
changed the title
|
@swift-ci please test |
|
Thanks for running the test and good to know it doesn't bother macOS and Linux. Windows platform failed with: We have to test in combination with swiftlang/swift#76894, because |
|
Please test with following PRs: @swift-ci please test |
|
Please test with following PRs: @swift-ci please test Windows Platform |
|
Same test summary as swiftlang/swift#76894. No flakes. Investigating the failures. |
We need the manual lookup in lldb/source/Host/windows/HostInfoWindowsSwift.cpp to succeed. Otherwise SwiftASTContext::CreateInstance() fails with: Cannot create Swift scratch context (couldn't load the Swift stdlib)
|
Please test with following PRs: @swift-ci please test Windows Platform |
…lit config These binaries only exists if the Swift runtime was built correctly. We cannot check them at configuration time, because they might not exist yet.
|
Please test with following PRs: @swift-ci please test Windows Platform |
|
The Swift rebranch landed and main now builds against the new stable branch (since compnerd/swift-build#840), so we need a new companion PR: #9513 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the companion PR with all the llvm-project changes for swiftlang/swift#76894