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

[Joel Brobecker]

> >> 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.
> 
> "catch fork" would make us stop though.

:-(. Most likely. I had the weekend to mull this over. The only
possible solutions I can see are:

  a. Make gdbserver "hide" the threads that are children of forks
     until we've reported the corresponding fork event to GDB.

     But then, I think it's unclear what to do if the user does
     a "step" or "continue" while you have multiple pending
     fork events. That's probably a question that's likely not
     specific to forks, as you might have the same issue when
     requesting an action after seeing the first of multiple
     events received at the same time. Perhaps simply just return
     the next event without resuming anything? Is that what we do?

  b. Somehow enhance GDB to handle the extra unknown threads
     more gracefully.

I don't really see how (b) could work. It seems that (a) would
be more promising. That said, I would still consider my current
patch, as reporting the forks early allow us to either detach
from them earlier.

-- 
Joel