[lldb-dap] Add breakpoints after debugger initialization in DExTer #169744
Conversation
This file contains hidden or 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
jeffreytan81
approved these changes
Nov 27, 2025
Contributor
jeffreytan81
left a comment
jeffreytan81
left a comment
There was a problem hiding this comment.
Makes sense. Accept to unblock buildbots.
GeneraluseAI
pushed a commit
to GeneraluseAI/llvm-project
that referenced
this pull request
Nov 27, 2025
…lvm#169744) # Summary This is a forward fix for test errors from llvm#163653. The PR moved debugger initialization outside of InitializeRequestHandler, and into Launch/AttachRequestHandlers to support DAP sessions sharing debugger instances for dynamically created targets. However, DExTer's DAP class seemed to set breakpoints before the debugger was initialized, which caused the tests to hang waiting for a breakpoint to hit due to none of the breakpoints getting resolved. # Tests ``` bin/llvm-lit -v /home/qxy11/llvm/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/ ```
Contributor
|
For some post-commit review (sorry for getting to this late!) - the sequencing here doesn't look correct according to the DAP specification. According to the specification, the
Dexter does not honor the first rule - there was/is no explicit wait for the Is it possible to implement the feature added in #163653 while also adhering to the DAP specification? As far as I can tell, the only necessary difference in terms of event sequencing would be to defer the response to the launch request until after the configurationDone response has been sent, or to accept configuration commands before sending the launch response, so that Dexter can still send requests in the order launch->breakpoints->configurationDone without conflicting with the debugger. |
augusto2112
pushed a commit
to augusto2112/llvm-project
that referenced
this pull request
Dec 3, 2025
…lvm#169744) # Summary This is a forward fix for test errors from llvm#163653. The PR moved debugger initialization outside of InitializeRequestHandler, and into Launch/AttachRequestHandlers to support DAP sessions sharing debugger instances for dynamically created targets. However, DExTer's DAP class seemed to set breakpoints before the debugger was initialized, which caused the tests to hang waiting for a breakpoint to hit due to none of the breakpoints getting resolved. # Tests ``` bin/llvm-lit -v /home/qxy11/llvm/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/ ```
SLTozer
added a commit
to SLTozer/llvm-project
that referenced
this pull request
Dec 3, 2025
Following PR llvm#169744 the DAP launch sequencing of Dexter was changed to complete a launch request/response before performing configuration steps. This matches LLDB's current behaviour, but is not compatible with the DAP specification and causes issues interfacing with other debuggers. This patch tries to bridge the gap by using a sequencing that is mostly DAP-compliant while still interfacing correctly with lldb-dap: we send a launch request first, then perform all configuration steps and sending configurationDone, and then awaiting the launch response. For lldb-dap, we do not wait for the launch response and may send configuration requests before it is received, but lldb-dap appears to handle this without issue. For other debug adapters, the launch request will be ignored until the configurationDone request is received and responded to, at which point the launch request will be acted upon and responded to. As an additional note, the initialized event should be sent after the initialize response and before the launch request according to the spec, but as LLDB currently sends it after the launch response Dexter has avoided checking for it. Since the initialized event is now being sent after the launch response by LLDB, we can start checking for it earlier in the sequence as well (though technically the client should receive the initialized event before it sends the launch request).
kcloudy0717
pushed a commit
to kcloudy0717/llvm-project
that referenced
this pull request
Dec 4, 2025
…lvm#169744) # Summary This is a forward fix for test errors from llvm#163653. The PR moved debugger initialization outside of InitializeRequestHandler, and into Launch/AttachRequestHandlers to support DAP sessions sharing debugger instances for dynamically created targets. However, DExTer's DAP class seemed to set breakpoints before the debugger was initialized, which caused the tests to hang waiting for a breakpoint to hit due to none of the breakpoints getting resolved. # Tests ``` bin/llvm-lit -v /home/qxy11/llvm/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/ ```
SLTozer
added a commit
that referenced
this pull request
Dec 9, 2025
) Following PR #169744 the DAP launch sequencing of Dexter was changed to complete a launch request/response before performing configuration steps. This matches LLDB's current behaviour, but is not compatible with the DAP specification and causes issues interfacing with other debuggers. This patch tries to bridge the gap by using a sequencing that is mostly DAP-compliant while still interfacing correctly with lldb-dap: we send a launch request first, then perform all configuration steps and send configurationDone, and then await the launch response. For lldb-dap, we do not wait for the launch response and may send configuration requests before it is received, but lldb-dap appears to handle this without issue. For other debug adapters, the launch request will be ignored until the configurationDone request is received and responded to, at which point the launch request will be acted upon and responded to. As an additional note, the initialized event should be sent after the initialize response and before the launch request according to the spec, but as LLDB currently sends it after the launch response Dexter has avoided checking for it. Since the initialized event is now being sent after the launch response by LLDB, we can start checking for it earlier in the sequence as well (though technically the client should receive the initialized event before it sends the launch request).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Summary
This is a forward fix for test errors from #163653.
The PR moved debugger initialization outside of InitializeRequestHandler, and into Launch/AttachRequestHandlers to support DAP sessions sharing debugger instances for dynamically created targets. However, DExTer's DAP class seemed to set breakpoints before the debugger was initialized, which caused the tests to hang waiting for a breakpoint to hit due to none of the breakpoints getting resolved.
Tests