When we send an interrupt request to debugserver we, sometimes, get one
extra spurious stop packet back.
This stop packet gets interpreted as a response to a qThreadStopInfo request
we make causing the protocol to become desynchronized for a while, until
eventually some kind of error appears.
Here's an example of this problem, distilled from issue #3013:
1 <- $vCont;c#a8
2 <- interrupt
3 -> $T05thread:12efb47;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,...
4 <- $qThreadStopInfo12efb8e#28
5 -> $T05thread:12efb47;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,...
6 <- $qThreadStopInfo12efb8f#29
7 -> $T00thread:12efb8e;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,...
8 <- $qThreadStopInfo12efb90#f4
9 -> $T00thread:12efb8f;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,...
10 <- $qThreadStopInfo12efb91#f5
11 -> $T00thread:12efb90;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,...
12 <- $qThreadStopInfo12efb47#f6
13 -> $T00thread:12efb91;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,...
14 <- $qThreadStopInfo12efb8d#27
15 -> $T05thread:12efb47;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,...
16 <- $p0;thread:12efb8e;#f5
17 -> $T00thread:12efb8d;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,...
response (3) is interpreted as the response to the vCont request at (1). We
then make a qThreadStopInfo request (4) and receive a stop packet in
response (5). Packet (5) is interpreted as the response to (4) but it
actually isn't, note how the thread ID is different, packet (5) is actually
a spurious stop packet sent by debug server. From response (5) onward the
protocol is desynchronized, none of the response we process are actually the
response to the preceding request.
This eventually causes a failure at packet (17) which debugserver sent as
the response to request (14) but we interpret as the response to (16).
Fixes#3013
2827145f1e