qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Win32 port [was: .previous in exec-all.h]


From: Mike Nordell
Subject: [Qemu-devel] Win32 port [was: .previous in exec-all.h]
Date: Fri, 19 Mar 2004 22:03:45 +0100

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





reply via email to

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