Getting gdbstub tcp::peek to fire while running

[lockbox]

My problem:
I'm running the gdbstub with a full implementation, and sending Ctrl+C. While the gdbstub is in the Idle state the polling does a blocking read and successfully reads data, and registers the interrupt packet is sent.

If the gdbstub is currently running, the custom peek sets the socket to non blocking and never successfully reads data from the socket. The moment it hit a breakpoint and stops (artificially added one that triggers at 20ish seconds into a spin loop), the gdbstub goes into the idle state and successfully reads bytes from the socket.

I'm on 18.04 Ubuntu, so there shouldn't be anything super exotic at play, any ideas on how to get the gdbstub peek to return any data while in the running state?

EDIT:
Tomorrow going to just provide a timeout to a blocking read and try every n cycles. But obviously this is going to slow things down

Relevant code snippet: basically copied from examples.

// inside of wait_for_stop_reason
        let poll_incoming_data = || {
            // gdbstub takes ownership of the underlying connection, so the `borrow_conn`
            // method is used to borrow the underlying connection back from the stub to
            // check for incoming data.
            let val = conn.peek().map(|b| b.is_some()).unwrap_or(true);

            if val == true {
                // val is *never* true
                warn!("polling closure for incoming data got: {val}");
            }
            val
        };

        match target.resume(poll_incoming_data) {
            // handle + propagate the client event (Never fires)
            RunEvent::IncomingData => {
                warn!("\t\t\tpoll detected incoming data");
                let byte = conn
                    .read()
                    .map_err(run_blocking::WaitForStopReasonError::Connection)?;
                Ok(run_blocking::Event::IncomingData(byte))
            }

[bet4it]

GDB supports this by adding a SIGIO handler. But I don't know how to implement this in Rust😅

[daniel5151]

I don't think the snippet of code you've offered has enough context for me to answer your question, since as per the docs:

The specific mechanism to “select” between these two events is implementation specific. Some examples might include: epoll, select! across multiple event channels, periodic polling, etc…

...and in your case, that selection mechanism is happening in your implementation of target.resume.

I don't know how you're using that function to poll for incoming data. In my examples - I run my emulator for some number of cycles and then invoke that callbacks, but you might be doing something else - I'm not sure.

@bet4it has suggested another interesting mechanism to accomplish this that I didn't point out via the docs (namely: using a SIGIO handler), and indeed, that approach could certainly be implemented in Rust (e.g: using something like https://docs.rs/signal-hook/latest/signal_hook/, plus some additional safe/unsafe code to do the fcntl stuff on the underlying socket fd).

Ultimately, you'll have to decide which approach is best suited for your application. Polling is "easy", but if you're running the target on the same thread as your server, you're going to need to periodically pause in order to check the socket. If you don't want to do this, you'll need to restructure your code appropriately.

[lockbox]

Yeah I'm not actually sure why it was failing as there's been no changes to that region of the codebase. I'm pretty sure something completely unrelated (async-timer and tokio killing things and UB heavy memes) were what was causing issues. TLDR; don't use those together. I'm pretty sure that was messing up the socket fd.

Either way, removed async timer and went back to timerfd and everything is hunkydory again. Thanks all for trying to help 🙂