================
@@ -893,10 +893,23 @@ llvm::Error DAP::Loop() {
return errWrapper;
}
+ // The launch sequence is special and we need to carefully handle
+ // packets in the right order. The launch and attach requests cannot
+ // be answered until we've gotten the confgigurationDone request. We
+ // can't answer the threads request until we've successfully launched
+ // or attached.
+ bool is_part_of_launch_sequence = false;
----------------
JDevlieghere wrote:
I like that idea. We can't quite move everything over to the other queue,
because the following requests can be made between the initialize and
configuration done request:
> In response to the initialized event, the development tool sends the
> configuration information using these requests:
>
> [setBreakpoints](https://microsoft.github.io/debug-adapter-protocol/specification#Requests_SetBreakpoints)
> one request for all breakpoints in a single source,
> [setFunctionBreakpoints](https://microsoft.github.io/debug-adapter-protocol/specification#Requests_SetFunctionBreakpoints)
> if the debug adapter supports function breakpoints,
> [setExceptionBreakpoints](https://microsoft.github.io/debug-adapter-protocol/specification#Requests_SetExceptionBreakpoints)
> if the debug adapter supports any exception options,
> [configurationDoneRequest](https://microsoft.github.io/debug-adapter-protocol/specification#Requests_ConfigurationDone)
> to indicate the end of the configuration sequence.
But limiting the ones that can be made is definitely more robust than what
we're doing now!
https://github.com/llvm/llvm-project/pull/138219
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
