On Sun, Apr 15, 2012 at 17:47, Stefan Weil <s...@weilnetz.de> wrote: > Am 15.04.2012 19:18, schrieb Blue Swirl: > >> On Sun, Apr 15, 2012 at 17:09, Stefan Weil <s...@weilnetz.de> wrote: >>> >>> Am 15.04.2012 19:02, schrieb Blue Swirl: >>> >>>> On Sun, Apr 15, 2012 at 14:13, Stefan Weil <s...@weilnetz.de> 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?