Re: [PATCH 02/23] Don't rely on inferior_ptid in record_full_wait

[Tom Tromey <tom@tromey.com>]

>> ... though not all returns set the kind.

Simon> Do you have an example?

No, I didn't notice that the wait_as function sets the kind at the
start.  So some minus_one_ptid returns seem to use
TARGET_WAITKIND_IGNORE.

>> I suspect the inf-ptrace targets can be converted by just lifting the
>> Linux code into in inf_ptrace_target.

Simon> Assuming there isn't too much Linux-ism in there.

I think the async bits are really just a pipe and the SIGCHLD stuff,
which is generic across ptrace-using Unixes.  (I'm not sure if that
works ok with procfs or not, I'm not familiar with that.)

>> /* The common code passes WNOHANG that leads to crashes, overwrite it.  */

Simon> Indeed, and that's a recent addition...

Yeah :(

>> Other targets require a little more research.  For Windows, Darwin, and
>> remote-sim, I thought perhaps we could put some of the current
>> resume/wait code into a separate thread.  (Though in the case of the
>> sim, I think it would be better to move the sims to using the remote
>> protocol.)

Simon> For Windows, that's what Pedro suggested here:
Simon> https://sourceware.org/legacy-ml/gdb/2016-09/msg00055.html

Simon> If we can avoid separate threads, I'd say it's better to, because it's more difficult
Simon> to debug.  For Windows, that would mean finding if there's an equivalent of SIGCHLD +
Simon> the self pipe trick but for Windows.  In other words, a way to wake up the event loop
Simon> when we know there's an event available.

There isn't a way on Windows.  A thread is preferable here since then
you don't have to poll -- the thread can just block in
WaitForDebugEvent.

Maybe we need to work around the mingw std::thread situation by
introducing our own gdb::thread and using Windows APIs there when
possible.

Tom