Re: [Qemu-devel] .previous in exec-all.h

["John R. Hogerhuis" <jhoger@speakeasy.net>]

[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]

On Fri, 2004-03-19 at 10:34, Pierre d'Herbemont wrote:
> On 16 mars 04, at 19:26, John R. Hogerhuis wrote:
> 
> > I haven't been able to find anything in the gnu assembler documentation
> > on .previous directive which is used in exec-all.h
> >
> > What does it do?
> 
> It means go back to the previous section. A work aroung would be to go  
> back to the .text section.
> (see:
> http://cvs.opendarwin.org/index.cgi/projects/darwine/related/qemu/exec-
> all.h?rev=1.1&content-type=text/x-cvsweb-markup


Thanks Pierre, that's helpful.

I'd like some advice from the group:

I'm wondering about whether it would make sense to go around my next
particular problem in the win32 port. 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. Some funniness in COFF is
forcing him to make every function have its own segment. This is
probably not a big issue.

I have an idea to drive around the COFF problem altogether. Since QEMU
is already able to generate i386 based code, I wonder whether it might
make sense to just generate a code generator for the Win32 port from the
ELF object file.

This would have dyngen.c generate, say <PROCESSOR>-codegen.c files which
in the case of targeting win32 platform would be i386-codegen.c which
would be target compiled into a COFF object file by Mingw. The code
dyngen would generate would be basically what it does now, except it
would also output initialized byte arrays containing the machine code as
C code.

It would read the code bytes from the op.o file, and output them into
codegen.c as initialized arrays of data. Then it would output a codegen
function which can copy the initialized array to arbitary location and
do the relocations... basically what's done now by op.h. op.h could be
generated as well, but it would only have function headers for the code
generation functions.

Right now dyngen is bound to ELF. My approach would leave it only bound
to ELF and not add an additional binding to COFF. My approach however
would not permit building on the Win32 platform itself unless you can
find a toolchain which can generate ELF format object files under
Windows.

Any obvious problems with either approach? And advantages or
disadvantages, roadblocks you can imagine in either? What are the
relative merits?

-- John.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]