> Am 28.02.2014 um 22:21 schrieb Peter Maydell <peter.mayd...@linaro.org>: > >> On 28 February 2014 14:12, Alex Bennée <alex.ben...@linaro.org> wrote: >> Is this "simply" a case of having a precise state in/around syscalls? > > No. > >> AIUI we already have such a mechanism for dealing with faults in >> translated code so this is all aimed at when an asynchronous signal >> arrives somewhere in QEMU's own code. > > The major problem is that system calls are supposed to be > atomic wrt signals, ie for the guest we must appear to > either take the signal first, or have the syscall return > EINTR, or take it after. Further, we mustn't make a host > syscall that is supposed to be interrupted by a signal if > the signal has already arrived, because we'll hang. > > http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00384.html > has a fuller description of the problem, though note that > my analysis of the solution is incorrect. I think Michael's > right that we could deal with this if we had known native > asm for the syscall sequence. (We probably want to separate > out the interruptible syscalls so we can continue to use > straightforward "just call libc" code for the bulk of them > which are non-interruptible.)
Could we check the instruction at the sognaling pc and check if it's a known syscall instruction? No need to replace glibc wrappers then. Alex > > thanks > -- PMM _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
