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

[Blue Swirl]

On Sun, Apr 15, 2012 at 17:47, Stefan Weil <address@hidden> wrote:
> 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.

Thanks for the explanation. Would similar hack as was done with GDB
for ELF help, so one day stack unwinding would work for generated
code?

> 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).

OK. BTW, have you tried to compile QEMU with MS compiler, would we
need a lot of changes to support that?