-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Add LLDB debugger support to swift-test command #9085
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
41c3aa6
to
5a8044c
Compare
@swift-ci please test |
} | ||
|
||
@Test(arguments: SupportedBuildSystemOnAllPlatforms) | ||
func debuggerFlagWithBothTestingSuites(buildSystem: BuildSystemProvider.Kind) async throws { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: Would there be an easy way to actually interact with LLDB during tests (eg,stdin
)? For instance, send it some commands and check back the expected results? Maybe you did it already... and I missed it :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the reasons this is still in draft is I want to address that. I think I'd have to add supplemental commands to the file that gets passed to LLDB that contains its setup commands. That would let us set specific breakpoints in tests, though I still haven't figured out how to inspect the output since we replace the running process with execv
.
a2b2ddf
to
9954eb4
Compare
@swift-ci test |
Introduces interactive debugging capabilities to `swift test` via a `--debugger` flag enabling developers to failing tests directly within LLDB. This adds debugging parity with `swift run --debugger` which allows users to debug their executables directly. When launching lldb this implenentation uses `execv()` to replace the `swift-test` process with LLDB. This approach avoids process hierarchy complications and ensures LLDB has full terminal control for interactive debugging features. When there is only one type of tests the debugger creates a single LLDB target configured specifically for that framework. For XCTest, this means targeting the test bundle with xctest as the executable, while Swift Testing targets the test binary directly with appropriate command-line arguments. When both testing frameworks have tests available we create multiple LLDB targets within a single debugging session. A Python script automatically switches targets as the executable exits, which lets users debug both types of tests spread across two executables in the same session. The Python script also maintains breakpoint persistence across target switches, allowing you to set a breakpoint for either test type no matter the active target. Finally, we add a `failbreak` command alias that sets breakpoint(s) that break on test failure, allowing users to automatically stop on failed tests. Issue: swiftlang#8129
6cb6b72
to
d916038
Compare
d916038
to
d056ae8
Compare
@swift-ci test windows |
Introduces interactive debugging capabilities to
swift test
via a--debugger
flag enabling developers to failing tests directly within LLDB.This adds debugging parity with
swift run --debugger
which allows users to debug their executables directly.When launching lldb this implenentation uses
execv()
to replace theswift-test
process with LLDB. This approach avoids process hierarchy complications and ensures LLDB has full terminal control for interactive debugging features.When there is only one type of tests the debugger creates a single LLDB target configured specifically for that framework. For XCTest, this means targeting the test bundle with xctest as the executable, while Swift Testing targets the test binary directly with appropriate command-line arguments.
When both testing frameworks have tests available we create multiple LLDB targets within a single debugging session. A Python script automatically switches targets as the executable exits, which lets users debug both types of tests spread across two executables in the same session. The Python script also maintains breakpoint persistence across target switches, allowing you to set a breakpoint for either test type no matter the active target.
Finally, we add a
failbreak
command alias that sets breakpoint(s) that break on test failure, allowing users to automatically stop on failed tests.Issue: #8129