ashgti wrote: > That said, does this actually solve the underlying problems? We know that VS > Code sends the launch and attach request before configuration done. It's > equally valid to not do that, and do things the way they're shown in the > sequence diagram, where you set breakpoints, then configuration done, then > launch or attach. Won't that still hit the same problem?
I think there are 2 specific problems that we have after ba29e60f9a2222bd5e883579bb78db13fc5a7588. 1. The pending request filter is somewhat fragile and for @da-viper use case of implementing support for [supportsDataBreakpointBytes](https://microsoft.github.io/debug-adapter-protocol//specification.html#Requests_DataBreakpointInfo) they're running into issues trying to respond to the `dataBreakpointInfo` request without access to a valid target but by not responding to the request, we're not getting `configurationDone`. 2. With the new launch flow, we're setting breakpoints before we've created a target, which is why I'm seeing us missing breakpoint events now when we used to not miss with `launchCommands`. As for the sequence, the flow has 2 parallel tracks that are independently triggered. The overall flow is: * After capabilities are returned from the initialize request trigger the `request launch` or `request attach` * After adapter sends `event initialized`, trigger the `setBreakpoints`, `setFunctionBreakpoints`, `setExceptionBreakpoints `, `setDataBreakpoints`, etc. followed by `configurationDone`. We're actually triggering the configuration flow by sending `event initialized` so we can adjust when that happens. Per the spec: > the debug adapter is expected to send an > [initialized](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Initialized) > event to the development tool to announce that it is ready to accept > configuration requests. With this approach a debug adapter does not have to > implement a buffering strategy for configuration information. Maybe we should look at moving the `initialized` event to after we've responded to the `launch`/`attach` commands instead of buffering or making them async. https://github.com/llvm/llvm-project/pull/140299 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
