From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B4R8v-0004Ex-PI for qemu-devel@nongnu.org; Fri, 19 Mar 2004 16:03:01 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B4R8N-0003ij-EJ for qemu-devel@nongnu.org; Fri, 19 Mar 2004 16:02:59 -0500 Received: from [81.228.9.107] (helo=av2-1-sn3.vrr.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B4R8M-0003h4-V9 for qemu-devel@nongnu.org; Fri, 19 Mar 2004 16:02:27 -0500 Message-ID: <001e01c40df5$b53cb620$0401a8c0@putte2k> From: "Mike Nordell" References: <1079461610.13515.34.camel@aragorn> <069E8780-79D4-11D8-A09D-000A2796D230@free.fr> <1079728362.20081.84.camel@aragorn> Subject: [Qemu-devel] Win32 port [was: .previous in exec-all.h] Date: Fri, 19 Mar 2004 22:03:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jhoger@pobox.com, Pierre d'Herbemont , qemu-devel@nongnu.org John R. Hogerhuis wrote: > Mike Nordell is further along than > I in a win32 port. He is replacing the ELF reading stuff in dyngen.c > with code that can process a coff .o file. Actually, he isn't anymore. AFAIK I have already done it. :-) The last thing I'm fighting is relative (REL32, IMAGE_REL_I386_REL32) relocations, that _sometimes_ seems to be wrong. I'm quite sure this is just me forgetting an extra indirection somewhere, which should be fixed in no-time, or perhaps even just the result of label_offsets being emitted with wrong values, something I fixed today but haven't had time to test-drive just yet. > Some funniness in COFF is forcing him to make every function > have its own segment. This is probably not a big issue. Considering section the only thing in a COFF object file telling the size of what it contains, it's obvious that each function has to be put in a section of its own, for dyngen to know how large a function is. But as you guessed; this is not a big issue. As for the actual execution environment, I believe the only major thing left is to get EBP inside generated code to actually point to "env", something that seems to be expected and required by the functions generated from op.c. It would be interesting to know how it's done on x86-host ELF systems. Is EBP somehow hard-wired to "env" (from cpu_exec() ), or am I possibly missing some prologue/epilogue native-code-generation to do this? /Mike - not a qemu devel subsciber, why I'd appreciate CC'd comments