Initialisation bug in gdb server

[Keith Robertson]

There's a minor bug in the initialisation of Till's gdb server.

Currently the daemon thread (D) runs at high priority and the helper 
thread (H) runs at low priority.

As far as I can discern from the code, H must execute in order to 
manually inject an interrupt and initialise the system.  D waits for 
this to occur in getFirstMsg called from rtems-stub.c:862.

However, if you call rtems_gdb_start from a thread (ie Init or I) with 
higher priority than H, then subsequently cause a breakpoint in I, 
without allowing H to run, then getFirstMsg returns and fails the assert 
on line 863.

In a three thread system, a hackish work around is to sleep after 
calling rtems_gdb_start and allow H to run.  A better fix is to ensure H 
has run and inserted the correct message prior to returning from 
rtems_gdb_start.

Thoughts?

I have a stab at a patch if anyone (Till?) is interested.

Cheers,

Keith