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 1B4QfJ-00083P-5b for qemu-devel@nongnu.org; Fri, 19 Mar 2004 15:32:25 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B4Qen-0007yJ-AJ for qemu-devel@nongnu.org; Fri, 19 Mar 2004 15:32:24 -0500 Received: from [216.254.0.205] (helo=mail5.speakeasy.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1B4Qem-0007y9-Uo for qemu-devel@nongnu.org; Fri, 19 Mar 2004 15:31:53 -0500 Subject: Re: [Qemu-devel] .previous in exec-all.h From: "John R. Hogerhuis" In-Reply-To: <069E8780-79D4-11D8-A09D-000A2796D230@free.fr> References: <1079461610.13515.34.camel@aragorn> <069E8780-79D4-11D8-A09D-000A2796D230@free.fr> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZEnSd7RKPtQPT1ikVVEt" Message-Id: <1079728362.20081.84.camel@aragorn> Mime-Version: 1.0 Date: Fri, 19 Mar 2004 12:32:42 -0800 Reply-To: jhoger@pobox.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pierre d'Herbemont , qemu-devel@nongnu.org Cc: Mike Nordell --=-ZEnSd7RKPtQPT1ikVVEt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-03-19 at 10:34, Pierre d'Herbemont wrote: > On 16 mars 04, at 19:26, John R. Hogerhuis wrote: >=20 > > 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? >=20 > It means go back to the previous section. A work aroung would be to go =20 > back to the .text section. > (see: > http://cvs.opendarwin.org/index.cgi/projects/darwine/related/qemu/exec- > all.h?rev=3D1.1&content-type=3Dtext/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? -- John. --=-ZEnSd7RKPtQPT1ikVVEt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAW1jqfY9MuGaNkEERAoJtAJ47rfHdkY0+QNClXfn5IIfqZECwBACgt63x 3iJyzTrWj/Gks11zh8fDDX0= =hbnB -----END PGP SIGNATURE----- --=-ZEnSd7RKPtQPT1ikVVEt--