The answer to your question is yes, this could be a strategy to
implement what the user "expects".

However I am not certain doing this in the stub/target side is the
"right thing to do" since I do not think this problem is peculiar to my
environment (plus it need to replicate some of the event handling that
is already being performed by the main event handler of GDB). Looking at
the implementation in infrun.c/infcmd.c, it seems, and I say this with
caution :-), that with a certain amount of fettling the existing code to
implement software stepping could be modified to support this scenario.

I have yet to look into this as a possible solution since it looks like
it could take a while to implement as I am not very familiar with this
part of GDB. For the time being I think I will just report an error if
the user attempts to step a thread which is not the last stopped thread
(or automatically switch to the stopped thread before stepping) and put
this on my to do list.

Also, while I was trying to absorb the mechanics of GDB in this area,
there seemed (to my untutored eye) an inconsistency between my target
definition setting "to_has_thread_control" to "tc_none" and the
execution model of infrun.c (esp. when it comes to stepping), or have I
missed something :-) ?

FYI I have attached the output of my test case when I use GDB 6.7.1
(with "set debug infrun 1"). As you can see there is no indication that
a context switch has occurred by the step; it seems that in GDB 6.7.1
changing threads did not alter the thread to be stepped (i.e. the last
stopped thread).

Cheers,

Antony.

Pedro Alves wrote:
> On Monday 18 August 2008 19:33:34, Antony KING wrote:
>> Thanks for the definition. I had not fully grasped this aspect of the
>> target_resume interface. For my target interface only mode (1) can be
>> properly supported. Modes (2) and (4) cannot be supported at all and
>> mode (3) can only be supported by ensuring that inferior_ptid is set to
>> the last stopped thread before commencing stepping.
>>
>> [Actually mode (4) can be supported but only if ptid == last stopped
>> thread, but this is the similar to supporting mode (3).]
>>
> 
> In your original example, would it work to put a special
> "switch-thread breakpoint" at the PC of thread 7, so it forces
> a thread switch on your target, and then continue hardware
> single-stepping from there when it is hit?  With care,
> it seems this could be hidden entirelly on the stub/target side.
> 
> (I'm still curious on how this worked on 6.7.1 though)