From what I can tell there is no message loop running for the windows.
It first thought it's supposed to be the message loop in Tcl_WaitForEvent(), but that one is overridden
with gdbtk_notifier_wait_for_event(), so that's not it.
As a workaround, I figured I could just (mis-)use the mingw gdb_select() implementation:
- event = WaitForMultipleObjects (num_handles,
+ event = MsgWaitForMultipleObjects (num_handles,
? (timeout->tv_sec * 1000
+ timeout->tv_usec / 1000)
- : INFINITE);
+ : INFINITE,
+ if (event == WAIT_OBJECT_0 + num_handles)
+ MSG msg;
+ while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
+ return 0;
/* EVENT can only be a value in the WAIT_ABANDONED_0 range if the
HANDLES included an abandoned mutex. Since GDB doesn't use
mutexes, that should never occur. */
Like this I can actually start doing something, but this doesn't look correct to me.
Also this is fine as long as the target isn't running because then I get stuck in target_wait.
From the comments above x_event() it seems that deprecated_ui_loop_hook() is supposed to take care of this,
and it actually is called in windows_nat_target::wait(), but then I just get into Tcl_WaitForEvent() as described earlier.
I'm also having a lot of problems with the UI, like error message dialogs when I press any button (even if it works),
but that's secondary until the message loop is working.