Re: [PATCH v8 6/7] Remote fork catch

[Pedro Alves <palves@redhat.com>]

On 04/17/2015 09:58 PM, Don Breazeal wrote:

>> > I think there's a race here, in non-stop mode.  Consider:
>> > 
>> >  #1 - process forks just before gdb starts fetching the remote thread
>> >       list.
>> >  #2 - gdbserver adds the fork child  its thread list.
>> >  #3 - gdbserver queues the fork event, sends vStopped notification
>> >  #4 - gdb/remote_update_thread_list pulls the thread list
>> >  #5 - we're now in remove_new_fork_child, but we don't know
>> >       about the fork event yet.  It's still pending in the vStopped
>> >       queue.
>> > 
>> > So I think that we need to make remote_update_thread_list do,
>> > in this order:
>> > 
>> >  #1 - fetch the remote thread list
>> >  #2 - fetch the pending vStopped notifications
>> >         (remote_notif_get_pending_events)
>> >  #3 - call remove_new_fork_child
>> >  #4 - add threads we don't know about yet to our list.
>> > 
>> > and make remove_new_fork_child also peek at the
>> > pending vStopped events queue (and in the future at
>> > any other layers of pending events in the core side.)
> I think all that was necessary here was to insert a call to
> remote_notif_get_pending_events before the call to remove_new_fork_child,
> since remote_notif_get_pending_events ultimately calls
> remote_parse_stop_reply on the responses from the target, handling the
> pending events like normal events.  Or am I missing something?  I 
> inferred from your comment above that there might be more to it.

It fetches the vStopped notifications out of the remote,
and parses them, but the events are left in the stop reply
queue, they're not handled.  They're only handled once the
core next calls target_wait -> remote_wait_ns -> queued_stop_reply.

So we need to peek into the stop reply queue, and check if we have
pending fork events.  We have peek_stop_reply for a similar use,
but it's not the same.

Thanks,
Pedro Alves