ashgti wrote: To clarify the DAP flow a little, see 'Launch Sequencing' in https://microsoft.github.io/debug-adapter-protocol/overview
Once the DAP server send the response to the `initialize` request the following happen in parallel: * The `initialized` event triggers the client sending `setBreakpoints`, etc. with the `configurationDone` request at the end of the chain. * `launch` or `attach` requests are sent and we send back a `process` event. The flow from VSCode at least often ends up with: * `initialize seq=1` * `launch seq=2` * `setBreakpoints seq=3` * `configurationDone seq=4` But these do not strictly have to be in that order. The DAP server can respond to these events asynchronously but today the lldb-dap is single threaded for handling each of these responses. Looking at the failing test https://lab.llvm.org/buildbot/#/builders/18/builds/15174/steps/6/logs/stdio, we had the following sequence: ``` {"command":"initialize", ...} {"command":"attach", ...} {"command":"setBreakpoints", ...} {"command":"configurationDone", ...} {"event":"stopped", ...} ``` But that stopped event here is wrong. This attach did not set `"stopOnEntry": true`, so that should have continued the process at point. https://github.com/llvm/llvm-project/pull/137920 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
