On Fri, 24 May 2019 at 11:46, Alex Bennée <alex.ben...@linaro.org> wrote: > > > Peter Maydell <peter.mayd...@linaro.org> writes: > > > On Thu, 23 May 2019 at 11:39, Alex Bennée <alex.ben...@linaro.org> wrote: > > I'm not sure about the "no callback" part of this API. The operation > > here is genuinely asynchronous and providing no mechanism for the > > caller to be able to say "ok, now wait til it completes" doesn't > > seem like a good plan. > > Well the caller doesn't really get a choice. At least in system mode > gdbstub does a vm_stop(RUN_STATE_DEBUG) and brings everything to a halt > anyway. All we've removed is the ability to tack on a callback (which > can get run in all sorts of contexts) when we restart.
gdb_do_syscall() is asynchronous -- it arranges for the syscall to happen, but makes no guarantee about when it will finish. At the moment the gdb_do_syscall() API allows the caller to cope with this asynchronousness, because when the callback is called the syscall has definitely finished. As it happens the callers are buggy in that they don't actually do the sync that they need to do, but we could fix that bug (ie post a semaphore in the callback function, and wait on it after the gdb_do_syscall() call). The API for this new function doesn't allow us to do that. > I could just drop the API here and allow the semihosting API to call > gdb_do_syscallv directly? I think we should either make the implementation of the function properly synchronous (ie do the post-semaphore-in-callback, wait-on-it-after-gdb_do_syscallv thing in the implementation, or have an API that lets callers do it. Perhaps we should just make gdb_do_syscall really be synchronous (ie have it do the semaphore stuff)? We only actually use it in semihosting, and I think all those cases require that the operation completes before we can resume execution of the guest CPU. So doing the synchronization in one place in the gdb code would be simpler than doing it separately in all the callers... thanks -- PMM