Re: RFA/gdbserver: GDB internal-error debugging threaded program with breakpoint and forks

[Joel Brobecker <brobecker@adacore.com>]

> I haven't gone through this with fine-tooth comb yet, but,
> will we still have the same problem if _two_ threads (or inferiors...)
> fork at the "same" time, and we end up reporting one fork, while
> leaving the another one pending?

At the moment, I do not think so, because we seem to just process
the fork even without requesting an update of the thread list.
This is an extract of the remote protocol transmissions that
show us resume the execution of our program (vCont;c), receive
the fork event (T05fork), do a bunch of stuff to handle the
fork event (and in particular "D"etaching from the child process),
followed by the resumption of our program's execution (vCont;c):

    Sending packet: $vCont;c:p2992.-1#b4...
    Packet received: T05fork:p299c.299c;01:bffff5e0;40:0fe87158;thread:p2992.2992;core:1;
    Sending packet: $Hgp299c.299c#5b...Packet received: OK
    Sending packet: $z0,1000224c,4#f2...Packet received: OK
    Sending packet: $z0,10003218,4#c5...Packet received: OK
    Sending packet: $z0,1000336c,4#f6...Packet received: OK
    Sending packet: $D;299c#86...Packet received: OK
    Sending packet: $vCont;c:p2992.-1#b4...Packet received: T05swbreak:;01:482009e0;40:10003218;thread:p2992.299a;core:0;

I wish I could give you a stronger justification, but at least
we seem to be OK, so the patch could give us a fix while we think
a more solid approach through.

-- 
Joel