qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Replace all setjmp()/longjmp() with sigsetjmp()


From: Stefan Weil
Subject: Re: [Qemu-devel] [PATCH] Replace all setjmp()/longjmp() with sigsetjmp()/siglongjmp()
Date: Mon, 18 Feb 2013 22:09:04 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11

Am 17.02.2013 21:13, schrieb Blue Swirl:
On Sun, Feb 17, 2013 at 2:44 PM, Peter Maydell<address@hidden>  wrote:
The setjmp() function doesn't specify whether signal masks are saved and
restored; on Linux they are not, but on BSD (including MacOSX) they are.
QEMU never wants to save and restore signal masks, because it uses threads,
and the signal-restoration may restore the whole process signal mask,
not just the mask for the thread which did the longjmp. In particular,
this resulted in a bug where ctrl-C was ignored on MacOSX because the
CPU thread did a longjmp which resulted in its signal mask being applied
to every thread, so that all threads had SIGINT and SIGTERM blocked.

The POSIX-sanctioned portable way to do a jump without affecting signal
masks is to use sigsetjmp() with a zero savemask parameter, so change
all uses of setjmp()/longjmp() accordingly.

For Windows we provide a trivial sigsetjmp/siglongjmp in terms of
setjmp/longjmp -- this is OK because no user will ever pass a non-zero
savemask (it would be a bug to do so because of the process-wide effects
described above).

The setjmp() uses in tests/tcg/test-i386.c and tests/tcg/linux-test.c
are left untouched because these are self-contained singlethreaded
test programs intended to be run under QEMU's Linux emulation, so they
have neither the portability nor the multithreading issues to deal with.

Signed-off-by: Peter Maydell<address@hidden>
---
This should have no visible effects on Linux where setjmp/longjmp
never messed with the signal state in the first place; it just makes
us behave right on the BSDs.

Stefan: I've put in the os-win32.h defines which I think are needed;
they're pretty trivial but I don't have a Win32 setup to compile with;
can I ask you to run a quick test for me, please?
Builds fine here on a few mingw32 setups.

So does it here.
The resulting binaries also work as expected (tested on w64).

Tested-by: Stefan Weil <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]