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

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

[John R. Hogerhuis]

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

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?

I am attempting to compile the core of qemu with Mingw32 cross compiler
under Debian. It is choking on these .previous directives as well as the
quotes around .data in

.section ".data"

The problem with .section is easily fixed in exec-all.h for my situation
but I don't know what to do about the .previous directive.

Thanks,

-- John.

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

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

[Mark IJbema]

On Tue, Mar 16, 2004 at 10:26:50AM -0800, 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?
> 
> I am attempting to compile the core of qemu with Mingw32 cross compiler
> under Debian. It is choking on these .previous directives as well as the
> quotes around .data in
> 
> .section ".data"
> 
> The problem with .section is easily fixed in exec-all.h for my situation
> but I don't know what to do about the .previous directive.

Are you tring to port qemu to windows? You might want to consider
dropping by in #reactos @ Freenode then and ask for tamlin, he's working
on it as well, i don't think he's on this list though.

Mark

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

[Pierre d'Herbemont]

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
)

Pierre

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

[John R. Hogerhuis]

[-- 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 --]

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

[Fabrice Bellard]

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.

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

[Mike Nordell]

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

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

[John R. Hogerhuis]

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

On Fri, 2004-03-19 at 12:58, Fabrice Bellard wrote:
> 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 :-)

It's just vaporware as of today (whereas Mike's idea is not). You can
implement it, if you like. Just mention my name in the changelog for the
design :-)

I think it's tres-cool if it can help Mac OS X port at the same time.

-- John,

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

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

[Pierre d'Herbemont]

On 19 mars 04, at 21:32, John R. Hogerhuis wrote:

> Right now dyngen is bound to ELF.

I have a send a patch which allows Mach-O Support to the list, but it 
is still pending due to its size. I'll resend it with using a http 
link. I really like your idea since it can really help the Mac OS X 
port and make Qemu more portable ;)

Pierre

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

[John R. Hogerhuis]

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

Here's an experimental patch to dyngen.c which generates the machine
code as byte arrays into op.h basically as I described.

Unfortunately I'm having problems with my cvs qemu at the moment (when I
run qemu I end up in the command line 'monitor' but I don't get a guest
window...), but from the op.h I generated, it *looks* like it is
working...

-- John.



[-- Attachment #2: dyngen.patch --]
[-- Type: text/x-patch, Size: 1597 bytes --]

Index: dyngen.c
===================================================================
RCS file: /cvsroot/qemu/qemu/dyngen.c,v
retrieving revision 1.31
diff -u -r1.31 dyngen.c
--- dyngen.c	17 Mar 2004 23:46:04 -0000	1.31
+++ dyngen.c	25 Mar 2004 09:26:03 -0000
@@ -652,7 +652,6 @@
             }
             fprintf(outfile, ";\n");
         }
-        fprintf(outfile, "    extern void %s();\n", name);
 
         for(i = 0, rel = relocs;i < nb_relocs; i++, rel++) {
             if (rel->r_offset >= start_offset &&
@@ -672,6 +671,33 @@
                     fprintf(outfile, "extern char %s;\n", sym_name);
                 }
             }
+        }
+
+        /* convert the code into a static array of bytes */
+        {
+          uint8_t *codep = text + start_offset;
+          int i = 0;
+          
+          fprintf(outfile, "    static const char %s[] =\n", name);
+          fprintf(outfile, "        {");
+          while (i < copy_size)
+          {
+            
+            /* emit the next byte of array */
+            fprintf (outfile, "'\\x%02X'", *codep);
+                
+            /* next byte */
+            i++, codep++;
+
+            /* exit loop if done */
+            if (i >= copy_size) break;
+
+            /* print comma, and also print newline if 8th byte */
+            fprintf (outfile, ", ");
+            if (i%8 == 0) fprintf (outfile, "\n         ");
+          }
+
+          fprintf (outfile, "};\n\n");
         }
 
         fprintf(outfile, "    memcpy(gen_code_ptr, (void *)((char *)&%s+%d), %d);\n", name, start_offset - offset, copy_size);

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

[John R. Hogerhuis]

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

I fixed my problem, and was able to test today with this patch and it
works fine.

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