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 1B4R4a-0002N2-Cl for qemu-devel@nongnu.org; Fri, 19 Mar 2004 15:58:32 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B4R2n-0001LW-68 for qemu-devel@nongnu.org; Fri, 19 Mar 2004 15:57:12 -0500 Received: from [193.252.22.22] (helo=mwinf0901.wanadoo.fr) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B4R2h-0001CT-Ds for qemu-devel@nongnu.org; Fri, 19 Mar 2004 15:56:35 -0500 Message-ID: <405B5EE2.1050506@bellard.org> Date: Fri, 19 Mar 2004 21:58:10 +0100 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] .previous in exec-all.h References: <1079461610.13515.34.camel@aragorn> <069E8780-79D4-11D8-A09D-000A2796D230@free.fr> <1079728362.20081.84.camel@aragorn> In-Reply-To: <1079728362.20081.84.camel@aragorn> Content-Type: text/plain; charset=us-ascii; format=flowed 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, qemu-devel@nongnu.org Cc: Mike Nordell 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 -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.