================
@@ -799,7 +799,33 @@ DNBProcessAttachWait(RNBContext *ctx, const char
*waitfor_process_name,
break;
}
- ::usleep(waitfor_interval); // Sleep for WAITFOR_INTERVAL, then poll
again
+ // Now we're going to wait a while before polling again. But we also
+ // need to check whether we've gotten an event from the debugger
+ // telling us to interrupt the wait. So we'll use the wait for a
possible
+ // next event to also be our short pause...
+ struct timespec short_timeout;
+ DNBTimer::OffsetTimeOfDay(&short_timeout, 0, waitfor_interval);
+ uint32_t event_mask = RNBContext::event_read_packet_available
+ | RNBContext::event_read_thread_exiting;
+ nub_event_t set_events = ctx->Events().WaitForSetEvents(event_mask,
+ &short_timeout);
+ if (set_events & RNBContext::event_read_packet_available) {
+ // If we get any packet from the debugger while waiting on the async,
+ // it has to be telling us to interrupt. So always exit here.
+ // Over here in DNB land we can see that there was a packet, but all
+ // the methods to actually handle it are protected. It's not worth
+ // rearranging all that just to get which packet we were sent...
+ DNBLogError("Interrupted by packet while waiting for '%s' to
appear.\n",
----------------
jasonmolenda wrote:
The structure of the gdb remote protocol is such that when you've sent a
packet, you can't send anything else until you get a response. "continue" is
special in that you can send ^C to the remote stub to interrupt execution. A
"waitfor" attach request most reasonably behaves the same as "continue" - the
only thing it would make any sense for the debugger to send when we're waiting
is ^C. If the debugger were to send anything else, yeah, something has gone
very wrong, but when Jim described the layering and how it wasn't
straightforward to check that, I didn't push further, it seemed fine to me to
assume the debugger didn't do something unsupported like send a non-interrupt
packet.
https://github.com/llvm/llvm-project/pull/72565
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
