Random notes about XBDM behavior:

There are two levels of execution control, a general "stop" state in which all threads are halted, and a thread-specific "halt" (suspend) state in which a single thread is stopped for some reason (e.g., a breakpoint). Thread suspension is nested within the general stop state, so if the program is stopped, all threads are stopped whether suspended or not. Similarly, if the program is started via "go", only threads that are not suspended will execute.

• The program execution state is controlled via the "stop" and "go" XBDM commands.
• The thread state may be changed via the "halt" and "continue" XBDM commands.
• When program execution is stopped, threads interrogated via the "isstopped" XBDM command will not report themselves as stopped unless they happened to be halted previously.
• It is possible to "continue" a halted thread in the execution "stopped" state, but this will not cause the program to change from "stopped" state.

There are a number of commands that may only be executed on suspended threads; generally it is probably most reliable to:

1. "stop"
2. "halt" a thread
3. "go" and await a state change to "stopped" state, allowing the system to hit the "halt" breakpoint.

Then to resume:

1. "continue" the stopped thread
2. "go" and await a state change back to the "started" state