> It seems reasonable to me, but while looking I ran across
> get_last_target_status.  Can we use that instead?  It isn't super to
> rely on globals like this, but existing globals are grandfathered in...
>

Yes. get_last_target_status works. I have updated the patch.

>
> Sami>  +                          gdbpy_breakpoint_from_bpstats (bs))<  0)
>
> I think it is possible for gdbpy_breakpoint_from_bpstats to return NULL.
> This is not really an error condition; it just means that this
> breakpoint has no corresponding Python object.
>
> I am not sure what to do in this case, but we definitely can't do this :-)
>

Hmm... We can just create the corresponding Python object, but shouldn't 
this situation be an error condition since gdbpy_breakpoint_created is 
observing breakpoint creation and creating the needed python objects ?

For now I added an error check, but I can modify 
gdbpy_breakpoint_created to allow us to reuse it and create the object 
if it is missing.

> Sami>  +  event = create_continue_event_object ();
>
> Are continue events symmetric to stop events, meaning that it should
> indicate which threads were continued?
>

Yes that is correct. I created a new event type called ThreadEvent to be 
a parent to all events which can be thread specific. Stop events and 
continue event are now children of thread event.

I also updated the test to test that the continue events are indeed 
being delivered to the intended thread, and that python reflects that. 
The documentation was also updated.

Sami