From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNIA7-0006dX-8C for qemu-devel@nongnu.org; Thu, 06 Aug 2015 06:12:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNIA2-0004uy-35 for qemu-devel@nongnu.org; Thu, 06 Aug 2015 06:12:35 -0400 Received: from [2a03:4000:1::4e2f:c7ac:d] (port=55472 helo=v220110690675601.yourvserver.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNIA1-0004ui-SI for qemu-devel@nongnu.org; Thu, 06 Aug 2015 06:12:30 -0400 Message-ID: <55C33305.4040502@weilnetz.de> Date: Thu, 06 Aug 2015 12:12:21 +0200 From: Stefan Weil MIME-Version: 1.0 References: <1438337876-13558-1-git-send-email-berrange@redhat.com> <55BB6EED.2010805@redhat.com> <55BBB755.1060503@weilnetz.de> <20150805095246.GB16246@redhat.com> <55C1ED97.2080005@weilnetz.de> <55C2405B.4050008@redhat.com> <6E1223CD-97D8-4675-AAFE-DF2F8298C8E1@livius.net> <55C27257.1010806@weilnetz.de> <20150806084432.GB4701@noname.str.redhat.com> In-Reply-To: <20150806084432.GB4701@noname.str.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QEMU 2.4 for Windows - current status List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Liviu Ionescu , QEMU Developer , Paolo Bonzini Am 06.08.2015 um 10:44 schrieb Kevin Wolf: > Am 05.08.2015 um 22:30 hat Stefan Weil geschrieben: >> Am 05.08.2015 um 20:39 schrieb Liviu Ionescu: >>>> On 05 Aug 2015, at 19:56, Paolo Bonzini wrote: >>>> >>>> ... I am not sure why things break for Stefan... >>> I confirm Stefan's conclusion, neither in my configuration adding >>> >>> #include "qemu-common.h" >>> >>> ... in cpu-exec.c makes any difference. >>> >>> however adding: >>> >>> #if defined(_WIN64) >>> #ifdef sigsetjmp >>> #undef sigsetjmp >>> #endif >>> #define sigsetjmp(env, savesigs) _setjmp(env, NULL) >>> #endif >>> >>> ... fixes the problem, my custom QEMU happily blinks the LEDs on Win 8.1 64-bits (see below). >>> >>> perhaps a headers check would be helpful, such mysterious behaviours usually back fire at a certain point. >>> >>> >>> regards, >>> >>> Liviu >> http://qemu.weilnetz.de/test/cpu-exec.i shows the result of >> the C preprocessor: >> >> cpu-exec.c gets QEMU's os-win32.h with our definition of setjmp >> early, but the system header file setjmp.h is included later, and >> that file re-defines our definitions. Including setjmp.h from >> os-win32.h would solve the problem, but I think there is a >> better solution. >> >> I am planning to remove the special definitions for _WIN64 from >> os-win32.h and add them to cpu-exec.c, similar to the code >> above (which can be shortened a little) >> but with some comment lines added. > What happens with the callers outside of cpu-exec.c then? Fixing the > problem inside os-win32.h seems more robust to me. > > Kevin (sig)setjmp/(sig)longjmp without TCG generated code on the stack does not need special handling because stack unwinding works for compiled normal C code. We only have a problem on 64 bit Windows with code generated at run time by TCG because stack unwinding does not work there, so a siglongjmp which tries to exit from that code will crash QEMU when trying to unwind the call stack. As far as I see, the only siglongjmp exits from TCG generated code are in cpu-exec.c (functions cpu_loop_exit and cpu_resume_from_signal). The matching sigsetjmp is also in cpu-exec.c, and here we have to disable stack unwinding by calling _setjmp(cpu->jmp_env, NULL). Stefan