The "do-nothing loop" in this routine, waiting for GDB to start successfully or fail to start before continuing to "->Prepare()" seems undeterministic, and the routine very likely to fail again sometime (as the comment preceding that loop indicates earlier failures as being the reason for its presence.)
Could that whole situation be made deterministic, by splitting the rest of the DoDebug below that into a separate method, and changing the loop to be wait until:
1)we've decided we've waited too long
2)the condition "!m_state_HasDriver()" is true
3)we've obtained a gdb version that is non-zero (over in GDB_driver::ParseOutput.)
and continuing to sleep (maybe longer) and yield as it does now?
Then the code in GDB_driver::ParseOutput() that encounters the "GNU gdb" version (for m_GDBVersionMajor/Minor) in some fashion initiates the rest of the code that was split off from the end of the current DoDebug() routine... (Not yet obvious to me whether it would be safe for ParseOutput() to simply invoke that second half directly or whether some other internal message/event would be required to trigger it, since it appears ParseOutput() may have the possibility of being asynchronously invoked while that loop is running).
[edit]
Maybe there is no need to split the later code in the routine - merely change the conditions of the loop as suggested, and wait "indefinitely" - with user being provided some means to cancel the activity, that could be checked and also be a terminating loop condition... ? (When are any 'cancel' debugging session commands activated, could they serve the user-cancellation need?)
