qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 07/20] w64: Fix definition of setjmp


From: Stefan Weil
Subject: Re: [Qemu-devel] [PATCH 07/20] w64: Fix definition of setjmp
Date: Sun, 15 Apr 2012 19:47:56 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20

Am 15.04.2012 19:18, schrieb Blue Swirl:
On Sun, Apr 15, 2012 at 17:09, Stefan Weil <address@hidden> wrote:
Am 15.04.2012 19:02, schrieb Blue Swirl:

On Sun, Apr 15, 2012 at 14:13, Stefan Weil <address@hidden> wrote:

The default definition of setjmp which is implemented in MinGW-w64
cannot be used with programs like QEMU which call longjmp from
code without structured exception handling (SEH).


We're currently compiling QEMU with -no-seh, is that correct for Mingw64?



Yes, that's correct. This code in configure is used for w32 and for w64:

# Use ASLR, no-SEH and DEP if available
if test "$mingw32" = "yes" ; then
   for flag in --dynamicbase --no-seh --nxcompat; do
       if $ld --help 2>/dev/null | grep ".$flag" >/dev/null 2>/dev/null ;
then
           LDFLAGS="-Wl,$flag $LDFLAGS"
       fi
   done
fi

See resulting file:

bin/debug/w64/config-host.mak:LDFLAGS=-Wl,--nxcompat -Wl,--no-seh
-Wl,--dynamicbase -Wl,--warn-common -m64 -g

Yes, but I meant that since Mingw64 uses SEH, does -Wl,--no-seh
conflict with Mingw64 SEH usage somehow? If yes, should we disable
no-seh for Mingw64 and could we also use plain setjmp() then?

Using --no-seh conflicts with the default which was set by MS
to use SEH on w64.

I don't know whether SEH makes any difference for C applications
like QEMU. Typically C code does not need stack unwinding,
therefore I don't think that SEH is really needed. I think that
MS wanted to improve the support of languages like C++ and .NET
which need SEH in their standard.

SEH increases the size of the exe file. If we only remove
--no-seh for w64, QEMU's JIT code will still not support
SEH, so I expect that longjmp will still crash when trying
to unwind the stack.

When QEMU is compiled to use TCI, that's no problem, and
stack unwinding works although we still compile using --no-seh
(I had a w64 version with TCI long before it worked with tcg/i386).




reply via email to

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