On 15 February 2012 16:55, Meador Inge <mead...@codesourcery.com> wrote: > This patch fixes the problem be staying in the 'RS_SYSCALL' state until next > packet read comes in. Therefore keeping any 'T' statuses from being sent > back to the GDB client while the syscall is still being processed.
Wouldn't it be more logical to stay in "we are processing a syscall" state until we actually get the whole reply packet and process it rather than merely until we get the first byte of the reply? (this probably implies it being a separate flag rather than an RSState state, but that's cleaner anyhow I think since the RSStates represent the state machine as we work through parsing the packet, and RS_SYSCALL isn't a distinct parsing state.) This patch works (in that it fixes this problem with a test case I have coincidentally received from another reporter this week), although I notice that doing read/write syscalls via gdb is dreadfully slow because there seems to be ~1second delay between gdb sending its response to a syscall (Fwrite/Fread) packet and getting the ack back from qemu. I'm guessing that's a different bug... -- PMM
