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

[Fabrice Bellard <fabrice@bellard.org>]

John R. Hogerhuis wrote:
> 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?

This is a very good idea and I like it as it means writing and 
maintaining less code ! It can also help the Mac OS X porting. I can do 
it if no one has already done it :-)

Fabrice.