Hello,

> As before though, all of these operations work fine using the remote 
> debugger, which was based on exactly the same code. I will try adding 
> some debug to the main gdb code today to see what it is up to.

OK, the cause of the problem is simple to find, I'm not so sure of a 
solution yet. The scenario at the time of the failure is as follows:

a) The main process stops (before any threads have been created)
b) A resume command is issued (continue or step). Since the current PC 
is a breakpoint though, the logic always requests a single step, handled 
in hardware on the PPC. The breakpoints are not re-installed for this.
c) The new thread is created, causing a notification event
d) After that event, all threads are resumed without step=1 so the 
program runs to completion/operator interrupt. The resume is handled 
directly at the target level, so breakpoints are not reinstated.

I tried to make the resume after the new thread notification preserve 
the step parameter value, but, although it stopped, I got a SIGTRAP 
exception message displayed and I was back at the original breakpoint in 
the main() function.

That is caused by the fact that the code is trying to switch to the main 
thread (top bit set), clearing the trap_expected value in the process 
(since the trap_expected value in the thread's state was initialised to 
zero when the thread was added to the list).

I'll take a closer look tomorrow to see if there's a simple fix...

Rgds,
John...