tree 43e95e441528bc38736555ac8ba48901525dc6fe
parent 4baa27895549f06dfad808d70ba0802877021c2b
author Tom Tromey <tromey@adacore.com> 1732133067 -0700
committer Tom Tromey <tromey@adacore.com> 1733777574 -0700

Defer DAP launch command until after configurationDone

PR dap/32090 points out that gdb's DAP "launch" sequencing is
incorrect.  The current approach (which is itself a 2nd
implementation...) was based on a misreading of the spec.  The spec
has since been clarified here:

    https://github.com/microsoft/debug-adapter-protocol/issues/497

The clarification here is that a client is free to send the "launch"
(or "attach") request at any point after the "initialized" event has
been sent by gdb.  However, the "launch" does not cause any action to
be taken -- and does not send a response -- until after
"configurationDone" has been seen.

This patch implements this by arranging for the launch and attach
commands to return a DeferredRequest object.

All the tests needed updates.  I've also added a new test that checks
that the deferred "launch" request can be cancelled.  (Note that the
cancellation is lazy -- it also waits until configurationDone is seen.
This could be fixed, but I was not sure whether it is important to do
so.)

Finally, the "launch" command has a somewhat funny sequencing now.
Simply sending the command and waiting for a response yielded strange
results if the inferior did not stop -- in this case, the repsonse was
never sent.  So now, the command is split into two parts, with some
setup being done synchronously (for better error propagation) and the
actual "run" being done async.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32090
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>