On 16 February 2012 18:39, Meador Inge <mead...@codesourcery.com> wrote: > On 02/15/2012 02:14 PM, Peter Maydell wrote: >> I think the right way to deal with both the problem you were seeing >> and this related issue is simply not to try to send the syscall >> request until we have really stopped the CPU. That is, when not >> in CONFIG_USER_ONLY we should send the syscall request from >> gdb_vm_state_change(). > > I agree. I am doing some more testing and will send an official v2 patch > later, but just to make sure I am on the right track something like (this > worked in the basic testing I have done so far and avoids the pitfall pointed > out above):
That looks roughly OK, but: * shouldn't gdb_syscall_buf[] be in GDBState ? * I don't think the "are we stopping to do a syscall?" flag should be implemented as an RSState enum -- that enum is for the parsing-incoming-packet state machine Bonus extra semihosting bug: if you start with "-gdb none" rather than "-s" then we segfault, because gdbserver_start() creates a GDBState with a NULL s->chr but use_gdb_syscalls() only looks at whether gdbserver_state is non-NULL, not whether s->state is RS_INACTIVE, so the first gdb_do_syscall() ends up dereferencing that NULL pointer. (Watch out when fixing this that you don't break semihosting in linux-user mode, because at the moment linux-user mode doesn't set up s->state at all so it's always RS_INACTIVE... We may also want to declare that mixing all of gdb, semihosting and fork() in a linux-user guest is not supported ;-)) -- PMM