qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] QEMU 2.4 for Windows - current status


From: Kevin Wolf
Subject: Re: [Qemu-devel] QEMU 2.4 for Windows - current status
Date: Thu, 6 Aug 2015 10:44:32 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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 <address@hidden> 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



reply via email to

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