[cdt-debug-dev] GDB MI problem with out-of-order commands

["Robb, Sam" <sam.robb@xxxxxxxxxxx>]

All,

We've discovered what appears to be a problem in the GDB
MI code.  I've verified that the problem exists in the
1.0.1 line, but haven't had the chance to test against
CVS head.

Apparently, it's possible to get into a state (particularly
when debugging using GDB server) where a second MI command
can be issued before the response to the first comes back.
You end up seeing trace output like the following:

1-command
2-command
1-command-response
3-command
2-command-response

...etc.  In our test case, we were able to reliably reproduce
a situation where the variables pane failed to update when
stepping through code after the first out-of-sequence command.

Taking a look at the GDB MI code, it wasn't apparent to me
whether or not the implementation was supposed to be able
to handle command sequences like this.  For our purposes,
we introduced the following workaround:

- Create an synchronization object shared by the GDB MI
  transmit thread and received thread.
- The tx thread sends a command, then waits on the sync
  object.
- When the rx thread receives a response, it signals the
  sync object.

This forces the two threads to work together (send response,
wait for response).  Not the best thing in the world, I think,
but it clears up the problem with out-of-step commands, and
corrects the problem with variable updates that we were seeing.

The workaround is (obviously) a bit heavy handed.  Has anyone
else come across this problem before?  If it is indeed a
problem with GDB MI, I'd prefer to find a real fix to the
problem, instead of relying on forced synchronization between
the rx/tx threads.

-Samrobb