I have checked the implementation and GDB is calling my target_resume
with a ptid of -1 (resume all threads), which I believe is the expected
argument (since scheduler locking is not supported). However I think I
will add an error check in my target_resume just in case GDB requests a
single thread to be resumed.

As you state, I think the best course of action for me is to modify GDB.
In order to preserve existing behaviour, I think the best solution is to
modify GDB so that it switches back to the original thread it stopped at
when performing a step operation (i.e. calling proceed() with step = 1).
I have attached my initial solution, which is to modify infcmd.c. This
is not entirely satisfactory as there needs to be some dynamic control
over this logic (so that it can be overridden) plus some input from the
target ops object.

Cheers,

Antony.

Daniel Jacobowitz wrote:
> On Mon, Aug 18, 2008 at 11:20:23AM +0100, Antony KING wrote:
>> Thanks for the explanation. Unfortunately GDB has no influence over the
>> RTOS, it is merely an observer. This means that it cannot change the
>> status of threads or decide which thread is to execute; this is solely
>> under the control of the RTOS.
> 
> If GDB has requested a step for a particular thread, and you're
> enabling hardware single step in your stub while another thread is
> current, I think this must be a bug in the stub.  It should, at the
> least, report an error instead of continuing.
> 
> That said, GDB hasn't been used in this way in a while, though it used
> to support it.  I think you'll need to communicate to GDB somehow that
> it can not change the executing thread.