diff mbox

QEMU 2.4 for Windows - current status

Message ID 55C2064B.2050606@redhat.com
State New
Headers show

Commit Message

Paolo Bonzini Aug. 5, 2015, 12:49 p.m. UTC
On 05/08/2015 13:03, Stefan Weil wrote:
> 
> Fix sigsetjmp for w64
> http://repo.or.cz/w/qemu/ar7.git/commit/8fa9c07c9a33174905e67589bea6be3e278712cb

Does this work too?


> slirp: Fix non blocking connect for w32
> http://repo.or.cz/w/qemu/ar7.git/commit/b3f21d56ad3f36562d396685de8ff4981af6b805

The second looks good, but you do not need the #ifdef at all in theory.
If you do, other breakage is looming.

Paolo

Comments

Stefan Weil Aug. 5, 2015, 3:38 p.m. UTC | #1
Am 05.08.2015 um 14:49 schrieb Paolo Bonzini:
> On 05/08/2015 13:03, Stefan Weil wrote:
>> Fix sigsetjmp for w64
>> http://repo.or.cz/w/qemu/ar7.git/commit/8fa9c07c9a33174905e67589bea6be3e278712cb
> Does this work too?
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index 75694f3..d882b89 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -17,6 +17,7 @@
>    * License along with this library; if not, see <http://www.gnu.org/licenses/>.
>    */
>   #include "config.h"
> +#include "qemu-common.h"
>   #include "cpu.h"
>   #include "trace.h"
>   #include "disas/disas.h"

No, that still gets the wrong definition for setjmp from
/usr/share/mingw-w64/include/setjmp.h.

For the future, I'd prefer a solution which restricts the special
handling of sigsetjmp to those locations where it is needed.
As far as I see, only cpu-exec.c uses sigsetjmp for returns
from generated code.

Maybe we can also add support for stack unwinding to the
generated code, so no special hack for w64 will be needed
anymore.

Stefan
Stefan Weil Sept. 10, 2015, 8:38 p.m. UTC | #2
Am 05.08.2015 um 14:49 schrieb Paolo Bonzini:
> On 05/08/2015 13:03, Stefan Weil wrote:
[...]
>> slirp: Fix non blocking connect for w32
>> http://repo.or.cz/w/qemu/ar7.git/commit/b3f21d56ad3f36562d396685de8ff4981af6b805
> 
> The second looks good, but you do not need the #ifdef at all in theory.
> If you do, other breakage is looming.
> 
> Paolo

The new code was this:

          if ((tcp_fconnect(so) == -1) &&
#if defined(_WIN32)
              socket_error() != WSAEWOULDBLOCK
#else
              (errno != EINPROGRESS) && (errno != EWOULDBLOCK)
#endif
          ) {

Without the preprocessor conditionals, Linux users would get
an undefined WSAEWOULDBLOCK.

And QEMU defines a macro EWOULDBLOCK which differs from
the MinGW-w64 definition, at least in my Debian Jessie
cross environment (10035 != 140):

include/sysemu/os-win32.h:
 # define EWOULDBLOCK  WSAEWOULDBLOCK

/usr/share/mingw-w64/include/pthread.h:
 #define EWOULDBLOCK	140
/usr/share/mingw-w64/include/psdk_inc/_wsa_errnos.h:
 #define WSAEWOULDBLOCK		(WSABASEERR + 35  )

That's only a problem if we get pthread.h when compiling
for Windows. Can we be sure that this won't happen?
It looks like Windows + MinGW(-w64) is a moving target
which is not so easy to handle.

Maybe it would be better to change tcp_fconnect() to
return an ANSI error code (with a conversion from
Windows error codes in that function).

Or we introduce a wrapper for connect(), qemu_connect().

Stefan
diff mbox

Patch

diff --git a/cpu-exec.c b/cpu-exec.c
index 75694f3..d882b89 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -17,6 +17,7 @@ 
  * License along with this library; if not, see <http://www.gnu.org/licenses/>.
  */
 #include "config.h"
+#include "qemu-common.h"
 #include "cpu.h"
 #include "trace.h"
 #include "disas/disas.h"