From mboxrd@z Thu Jan 1 00:00:00 1970 From: Todd Whitesel To: fnasser@redhat.com (Fernando Nasser) Cc: msalter@redhat.com, ac131313@cygnus.com, gdb@sources.redhat.com Subject: Re: gdb/remote - I/O Date: Thu, 29 Mar 2001 23:10:00 -0000 Message-id: <200103300709.XAA28219@shell17.ba.best.com> References: <3ABFA8D1.DA0D2EAE@redhat.com> X-SW-Source: 2001-03/msg00319.html > 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" > 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