On certain architectures, the GDB client doesn't seem to respect `vCont?` responses that don't include `;s;S`, and will unconditionally send single-step resume packets, even when the target has not explicitly acknowledges support.

e.g: when connected to a x86_64 target:

  Sending packet: $vCont?#49...Packet received: vCont;c;C
  Packet vCont (verbose-resume) is supported
  Sending packet: $vCont;s:p1.1;c:p1.-1#f7...Remote connection closed

Interestingly enough, this is _not_ the case for all architectures. When connected to an `armv4t` target:

  Sending packet: $vCont?#49...Packet received: vCont;c;C
  Packet vCont (verbose-resume) is supported
  Sending packet: $m55550000,4#61...Packet received: 00000000
  Sending packet: $m55550000,4#61...Packet received: 00000000
  Sending packet: $m55550004,4#65...Packet received: 00000000
  Sending packet: $m55550000,4#61...Packet received: 00000000
  Sending packet: $m55550000,4#61...Packet received: 00000000
  Sending packet: $m55550000,4#61...Packet received: 00000000
  Sending packet: $Z0,55550004,4#ae...Packet received:
  Packet Z0 (software-breakpoint) is NOT supported
  Sending packet: $m55550004,4#65...Packet received: 00000000
  Sending packet: $X55550004,0:#86...Packet received: OK
  binary downloading supported by target
  Sending packet: $X55550004,4:\001\000\237�#19...Packet received: OK
  Sending packet: $vCont;c:p1.-1#0f

Which is what I would expect (i.e: it attempts to set a temporary software breakpoint, and then continues the target).

* * *

While looking into this bug, I created a basic set of "dummy" remote targets to figure out why this was happening. I've uploaded these targets to Github, in hope that they can be useful while looking into this bug:

https://github.com/daniel5151/gdb-optional-step-bug

For more context, here is the (unrelated) issue where I stumbled across this bug:

https://github.com/daniel5151/gdbstub/issues/89#issuecomment-939203794