Re: gdb/remote - I/O

[Todd Whitesel <toddpw at best dot com>]

> However, this now puts GDB in an "inferior input" state, as state that
> we did not have before). At what level will this be handled?
> 
> There are several details that have to be sorted out as well, like if
> the "i" packet does not have all the input needed by the read to
> continue what should the target do?  Maybe issue another "T<SIGTTIN>"
> until it gets all the data it needs.  On the other extreme the user may
> have typed ahead.  We can just have the stub discard those (but if we
> have echoed the characters typed on the GDB console this can be
> confusing).

I prefer the implementation where target I/O is treated like a general
syscall request, which always blocks on the host. After all, it's really
for debugging and bootstrapping, not production -- and you gain a lot of
flexibility by doing it this way.

On the target, a syscall acts just like a breakpoint except that some
extra "I'm a syscall!" information is sent up too. For example, the
syscall number and the first three argument registers, which covers
all of your basic syscalls.

The target then just sits and waits to be manipulated with register/memory
commands, and eventually gets a command sequence telling it to write the
return register and 'errno flag' register and to continue.

On the host, a target that stops on a syscall gets processed through logic
which feels somewhat like the "should we continue stepping or not?" paths
in The Code Formerly Known As WaitForInferior. The host translates the
syscall to native bit-flags and such and attempts to execute it, including
simulated I/O (you need some minimal buffering here, nothing complicated).

If the requested syscall completes immediately, great. Diddle the target
and resume it. But if it doesn't, then you put the inferior into a state
which says "blocked on I/O" that is generally equivalent to "running" but
tells the event loop to keep checking to see if the target I/O can be
completed. Presumably this involves some combination of select/poll,
non-blocking read's, interaction with GUI's, etc.

The main things to keep straight are that the target PC has to remain at
the syscall instruction itself UNTIL the syscall is completed. This allows
you to process a user-level stop request by simply dropping the syscall and
declaring the target stopped. If the target is then continued at the same
PC, the syscall is simply re-executed.

Todd Whitesel
toddpw @ best.com