From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJR4q-00085e-7F for qemu-devel@nongnu.org; Fri, 28 Feb 2014 12:18:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJR4l-0003uI-SW for qemu-devel@nongnu.org; Fri, 28 Feb 2014 12:18:24 -0500 Received: from mail-la0-f51.google.com ([209.85.215.51]:47676) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJR4l-0003u5-M6 for qemu-devel@nongnu.org; Fri, 28 Feb 2014 12:18:19 -0500 Received: by mail-la0-f51.google.com with SMTP id pv20so2098525lab.24 for ; Fri, 28 Feb 2014 09:18:18 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <87mwhbf9ni.fsf@linaro.org> References: <87sirhyi1b.fsf@linaro.org> <87txbnfuw1.fsf@linaro.org> <530C5925.8060608@suse.de> <87ppm7fhsb.fsf@linaro.org> <4B6FA9D8-356D-47D1-A270-C71A1216B305@suse.de> <87mwhbf9ni.fsf@linaro.org> From: Peter Maydell Date: Fri, 28 Feb 2014 17:17:58 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Cc: linaro-dev , Dann Frazier , Michael Matz , Alexander Graf , "linaro-toolchain@lists.linaro.org" , qemu-devel , Wook Wookey , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Christoffer Dall On 28 February 2014 17:08, Alex Benn=C3=A9e wrote: > > Peter Maydell writes: > >> On 28 February 2014 14:27, Alexander Graf wrote: >>> 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. >> >> No, because the behaviour we want for "started handling >> syscall in qemu" through to "PC anything up to but not >> including the syscall insn" is "back out and take signal >> then try again", which means we need to be able to unwind >> anything we were doing. If we (effectively) longjmp out of >> the middle of glibc we're liable to leave locked mutexes >> and otherwise mess up glibc internals. > > The other option is roll the real PC forward until you know you are at a > point that everything is in a known state - in this case a labelled > syscall instruction. I don't see how rolling the host PC forward would work. We can't take the guest signal where we are, we can't go forward because that would imply executing the host syscall (which might now block): the only thing we can do is roll back to a point where we can make it appear we hadn't executed the guest syscall insn yet, and then take the guest signal. Masking signals doesn't work in general because you need the signal to be unblocked while you do the host syscall (so it can correctly return EINTR if the signal comes in while it's doing stuff), and there's no way to atomically unblock-and-do-syscall (and certainly no way to do that if your syscall is buried inside glibc). thanks -- PMM