Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation

From: Peter Maydell <peter.maydell@linaro.org>
To: Alexander Graf <agraf@suse.de>
Cc: linaro-dev <linaro-dev@lists.linaro.org>,
	"Dann Frazier" <dann.frazier@canonical.com>,
	"Michael Matz" <matz@suse.de>, qemu-devel <qemu-devel@nongnu.org>,
	"linaro-toolchain@lists.linaro.org"
	<linaro-toolchain@lists.linaro.org>,
	"Wook Wookey" <wookey@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Andreas Färber" <afaerber@suse.de>,
	"Christoffer Dall" <Christoffer.Dall@linaro.org>
Subject: Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
Date: Fri, 28 Feb 2014 14:49:58 +0000	[thread overview]
Message-ID: <CAFEAcA_w-j_bRS1AHAWV=r8DmncgFPbOnR=hE2y9uHE2ia1QHw@mail.gmail.com> (raw)
In-Reply-To: <4B6FA9D8-356D-47D1-A270-C71A1216B305@suse.de>

On 28 February 2014 14:27, Alexander Graf <agraf@suse.de> 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. Also we need to be
able to distinguish "not got to syscall insn yet" from
"after syscall insn", which isn't possible to determine
if all you have is "PC is inside glibc but not actually
at the syscall insn".

There really aren't all that many interruptible syscalls,
though, so we can probably live with handrolling those.

thanks
-- PMM