[Qemu-devel] [patch] make qemu work with GCC 4

[Qemu-devel] [patch] make qemu work with GCC 4

[Michael Matz]

Hi,

[please keep me CCed, I'm not on this list]

the below patch let's qemu be compiled by GCC 4.2 (probably also 4.1 and 
others) for most hosts (i386,x86_64,ia64,ppc).  s390 as host is missing, 
and needs a compiler change to emit the literal store inline again, as the 
literal pool at the end fundamentally breaks the assumption that qemu can 
paste together the code snippets by patching out the return.  I have no 
HOST_{ARM,MIPS*,ALPHA,SPARC*,M68K} machines to compile for that.

It specifically changes these things:

* ppc: adds -fno-section-anchors to OP_CFLAGS, as dyngen isn't prepared
       to deal with the relocs resulting from using section anchors
* ppc: on target-alpha op_reset_FT GCC4 uses a floating point constant 0.0
       to reset the ft regs, which in turn is loaded from the data 
       section.  The reloc for that is unhandled.  Using -ffast-math would 
       work around this, but I chose to be conservative and change only
       the op.c snippet in question.  See the comment there.
* i386: well, most of you will know that GCC4 doesn't compile qemu because 
       of reload.  The inherent problem is, that qemu uses 64bit
       entities in some places (sometimes structs), which GCC (4.x) 
       manages to place in registers, i.e. needs 2 hardregs.  But it 
       sometimes just so happens that an instruction needing such DImode
       reg also has a memory operand with an indexed address (reg plus 
       reg), hence two hardregs more.  But qemu by default leaves just 
       three free registers for compiling op.c --> boom.  This is somewhat 
       hard to work around in GCC (trust me :) ).

       I solved that by placing one of the T[012] operands into memory
       for HOST_I386, thereby freeing one reg.  Here's some justification 
       of why that doesn't really cost performance: with three free regs
       GCC is already spilling like mad in the snippets, we just trade one
       of those memory accesses (to stack) with one other mem access to 
       the cpu_state structure, which will be in cache.

       Additionally I made sure that I put the least used Tx global into 
       memory.  I haven't done much performance measurements but noticed 
       no glaring problems.

       Two more obvious changes in an inline asm in softmmu_header.h were 
       necessary too.

A qemu with that patch was tested on HOST_I386 with all images from the 
qemu homepage (i.e. arm, mips, mipsel, coldfire (that doesn't work) and 
sparc), some i386 boot isos and a freedos image.  It also was tested on 
HOST_X86_64 installing openSUSE beta-something for i386 and x86_64.  I 
haven't yet tested it on ia64 or ppc hosts.

The whole patch is against a 0.9.0-cvs version from 2007-07-09 (Alex might 
know the exact checkout date), so chances are that it still applies :)


Ciao,
Michael.

diff -urp qemu-0.9.0.cvs.orig/softmmu_header.h qemu-0.9.0.cvs/softmmu_header.h
--- qemu-0.9.0.cvs.orig/softmmu_header.h	2007-08-21 18:58:00.000000000 +0200
+++ qemu-0.9.0.cvs/softmmu_header.h	2007-08-21 20:40:23.000000000 +0200
@@ -254,14 +254,18 @@ static inline void glue(glue(st, SUFFIX)
                   : "r" (ptr), 
 /* NOTE: 'q' would be needed as constraint, but we could not use it
    with T1 ! */
+#if DATA_SIZE == 1 || DATA_SIZE == 2
+		  "q" (v),
+#else
                   "r" (v), 
+#endif
                   "i" ((CPU_TLB_SIZE - 1) << CPU_TLB_ENTRY_BITS), 
                   "i" (TARGET_PAGE_BITS - CPU_TLB_ENTRY_BITS), 
                   "i" (TARGET_PAGE_MASK | (DATA_SIZE - 1)),
                   "m" (*(uint32_t *)offsetof(CPUState, tlb_table[CPU_MEM_INDEX][0].addr_write)),
                   "i" (CPU_MEM_INDEX),
                   "m" (*(uint8_t *)&glue(glue(__st, SUFFIX), MMUSUFFIX))
-                  : "%eax", "%ecx", "%edx", "memory", "cc");
+                  : "%eax", "%edx", "memory", "cc");
 }
 
 #else
diff -urp qemu-0.9.0.cvs.orig/target-alpha/cpu.h qemu-0.9.0.cvs/target-alpha/cpu.h
--- qemu-0.9.0.cvs.orig/target-alpha/cpu.h	2007-06-03 23:02:37.000000000 +0200
+++ qemu-0.9.0.cvs/target-alpha/cpu.h	2007-08-22 00:54:15.000000000 +0200
@@ -278,6 +278,8 @@ struct CPUAlphaState {
      * used to emulate 64 bits target on 32 bits hosts
      */ 
     target_ulong t0, t1, t2;
+#elif defined(HOST_I386)
+    target_ulong t2;
 #endif
     /* */
     double ft0, ft1, ft2;
diff -urp qemu-0.9.0.cvs.orig/target-alpha/exec.h qemu-0.9.0.cvs/target-alpha/exec.h
--- qemu-0.9.0.cvs.orig/target-alpha/exec.h	2007-06-03 19:44:36.000000000 +0200
+++ qemu-0.9.0.cvs/target-alpha/exec.h	2007-08-21 21:28:58.000000000 +0200
@@ -40,7 +40,11 @@ register struct CPUAlphaState *env asm(A
 
 register uint64_t T0 asm(AREG1);
 register uint64_t T1 asm(AREG2);
+#ifndef HOST_I386
 register uint64_t T2 asm(AREG3);
+#else
+#define T2 (env->t2)
+#endif
 
 #endif /* TARGET_LONG_BITS > HOST_LONG_BITS */
 
diff -urp qemu-0.9.0.cvs.orig/target-arm/cpu.h qemu-0.9.0.cvs/target-arm/cpu.h
--- qemu-0.9.0.cvs.orig/target-arm/cpu.h	2007-06-24 14:09:48.000000000 +0200
+++ qemu-0.9.0.cvs/target-arm/cpu.h	2007-08-21 21:38:36.000000000 +0200
@@ -52,6 +52,9 @@ typedef uint32_t ARMReadCPFunc(void *opa
  */
 
 typedef struct CPUARMState {
+#if defined(HOST_I386)
+    uint32_t t1;
+#endif
     /* Regs for current mode.  */
     uint32_t regs[16];
     /* Frequently accessed CPSR bits are stored separately for efficiently.
diff -urp qemu-0.9.0.cvs.orig/target-arm/exec.h qemu-0.9.0.cvs/target-arm/exec.h
--- qemu-0.9.0.cvs.orig/target-arm/exec.h	2007-06-03 19:44:36.000000000 +0200
+++ qemu-0.9.0.cvs/target-arm/exec.h	2007-08-21 21:48:48.000000000 +0200
@@ -23,7 +23,12 @@
 register struct CPUARMState *env asm(AREG0);
 register uint32_t T0 asm(AREG1);
 register uint32_t T1 asm(AREG2);
+#ifndef HOST_I386
 register uint32_t T2 asm(AREG3);
+#else
+#define T2 (env->t1)
+#endif
+
 
 /* TODO: Put these in FP regs on targets that have such things.  */
 /* It is ok for FT0s and FT0d to overlap.  Likewise FT1s and FT1d.  */
diff -urp qemu-0.9.0.cvs.orig/target-i386/cpu.h qemu-0.9.0.cvs/target-i386/cpu.h
--- qemu-0.9.0.cvs.orig/target-i386/cpu.h	2007-06-03 23:02:37.000000000 +0200
+++ qemu-0.9.0.cvs/target-i386/cpu.h	2007-08-21 21:16:47.000000000 +0200
@@ -427,6 +427,8 @@ typedef struct CPUX86State {
 #if TARGET_LONG_BITS > HOST_LONG_BITS
     /* temporaries if we cannot store them in host registers */
     target_ulong t0, t1, t2;
+#elif defined(HOST_I386)
+    target_ulong t1;
 #endif
 
     /* standard registers */
diff -urp qemu-0.9.0.cvs.orig/target-i386/exec.h qemu-0.9.0.cvs/target-i386/exec.h
--- qemu-0.9.0.cvs.orig/target-i386/exec.h	2007-06-26 10:35:18.000000000 +0200
+++ qemu-0.9.0.cvs/target-i386/exec.h	2007-08-21 21:30:40.000000000 +0200
@@ -44,7 +44,11 @@ register struct CPUX86State *env asm(ARE
 /* XXX: use unsigned long instead of target_ulong - better code will
    be generated for 64 bit CPUs */
 register target_ulong T0 asm(AREG1);
+#ifndef HOST_I386
 register target_ulong T1 asm(AREG2);
+#else
+#define T1 (env->t1)
+#endif
 register target_ulong T2 asm(AREG3);
 
 /* if more registers are available, we define some registers too */
diff -urp qemu-0.9.0.cvs.orig/target-mips/cpu.h qemu-0.9.0.cvs/target-mips/cpu.h
--- qemu-0.9.0.cvs.orig/target-mips/cpu.h	2007-06-23 20:04:11.000000000 +0200
+++ qemu-0.9.0.cvs/target-mips/cpu.h	2007-08-21 21:17:23.000000000 +0200
@@ -60,7 +60,10 @@ struct CPUMIPSState {
     target_ulong t0;
     target_ulong t1;
     target_ulong t2;
+#elif defined(HOST_I386)
+    target_ulong t1;
 #endif
+    
     target_ulong HI, LO;
     /* Floating point registers */
     fpr_t fpr[32];
diff -urp qemu-0.9.0.cvs.orig/target-mips/exec.h qemu-0.9.0.cvs/target-mips/exec.h
--- qemu-0.9.0.cvs.orig/target-mips/exec.h	2007-06-03 19:44:36.000000000 +0200
+++ qemu-0.9.0.cvs/target-mips/exec.h	2007-08-21 21:37:06.000000000 +0200
@@ -17,7 +17,11 @@ register struct CPUMIPSState *env asm(AR
 #else
 register target_ulong T0 asm(AREG1);
 register target_ulong T1 asm(AREG2);
+#ifndef HOST_I386
 register target_ulong T2 asm(AREG3);
+#else
+#define T2 (env->t1)
+#endif
 #endif
 
 #if defined (USE_HOST_FLOAT_REGS)
diff -urp qemu-0.9.0.cvs.orig/target-ppc/cpu.h qemu-0.9.0.cvs/target-ppc/cpu.h
--- qemu-0.9.0.cvs.orig/target-ppc/cpu.h	2007-06-23 18:02:43.000000000 +0200
+++ qemu-0.9.0.cvs/target-ppc/cpu.h	2007-08-21 21:19:57.000000000 +0200
@@ -694,6 +694,8 @@ struct CPUPPCState {
      * used to emulate 64 bits target on 32 bits hosts
      */ 
     target_ulong t0, t1, t2;
+#elif defined(HOST_I386)
+    target_ulong t1;
 #endif
     ppc_avr_t t0_avr, t1_avr, t2_avr;
 
diff -urp qemu-0.9.0.cvs.orig/target-ppc/exec.h qemu-0.9.0.cvs/target-ppc/exec.h
--- qemu-0.9.0.cvs.orig/target-ppc/exec.h	2007-06-03 19:44:36.000000000 +0200
+++ qemu-0.9.0.cvs/target-ppc/exec.h	2007-08-21 21:41:41.000000000 +0200
@@ -40,7 +40,11 @@ register struct CPUPPCState *env asm(ARE
 #else
 register unsigned long T0 asm(AREG1);
 register unsigned long T1 asm(AREG2);
+#ifndef HOST_I386
 register unsigned long T2 asm(AREG3);
+#else
+#define T2 (env->t1)
+#endif
 #endif
 /* We may, sometime, need 64 bits registers on 32 bits target */
 #if defined(TARGET_PPC64) || defined(TARGET_PPCEMB) || (HOST_LONG_BITS == 64)
diff -urp qemu-0.9.0.cvs.orig/target-sparc/exec.h qemu-0.9.0.cvs/target-sparc/exec.h
--- qemu-0.9.0.cvs.orig/target-sparc/exec.h	2007-06-03 19:44:37.000000000 +0200
+++ qemu-0.9.0.cvs/target-sparc/exec.h	2007-08-21 21:26:38.000000000 +0200
@@ -32,9 +32,13 @@ register uint32_t T2 asm(AREG4);
 
 #else
 #define REGWPTR env->regwptr
+#ifndef HOST_I386
 register uint32_t T2 asm(AREG3);
-#endif
 #define reg_T2
+#else
+#define T2 (env->t2)
+#endif
+#endif
 #endif
 
 #define FT0 (env->ft0)
diff -urp qemu-0.9.0.cvs.orig/target-z80/cpu.h qemu-0.9.0.cvs/target-z80/cpu.h
--- qemu-0.9.0.cvs.orig/target-z80/cpu.h	2007-08-21 18:58:00.000000000 +0200
+++ qemu-0.9.0.cvs/target-z80/cpu.h	2007-08-21 21:14:37.000000000 +0200
@@ -147,6 +147,8 @@ typedef struct CPUZ80State {
 #if TARGET_LONG_BITS > HOST_LONG_BITS
     /* temporaries if we cannot store them in host registers */
     target_ulong t0, t1, t2;
+#elif defined(HOST_I386)
+    target_ulong t1;
 #endif
 
     /* Z80 registers */
diff -urp qemu-0.9.0.cvs.orig/target-z80/exec.h qemu-0.9.0.cvs/target-z80/exec.h
--- qemu-0.9.0.cvs.orig/target-z80/exec.h	2007-08-21 18:58:00.000000000 +0200
+++ qemu-0.9.0.cvs/target-z80/exec.h	2007-08-21 21:13:47.000000000 +0200
@@ -40,7 +40,11 @@ register struct CPUZ80State *env asm(ARE
 /* XXX: use unsigned long instead of target_ulong - better code will
    be generated for 64 bit CPUs */
 register target_ulong T0 asm(AREG1);
+#ifdef HOST_I386
+#define T1 (env->t1)
+#else
 register target_ulong T1 asm(AREG2);
+#endif
 register target_ulong T2 asm(AREG3);
 
 /* if more registers are available, we define some registers too */
--- qemu-0.9.0.cvs.orig/Makefile.target	2007-08-21 18:58:01.000000000 +0200
+++ qemu-0.9.0.cvs/Makefile.target	2007-08-22 02:02:55.000000000 +0200
@@ -127,6 +127,7 @@ endif
 
 ifeq ($(ARCH),ppc)
 CPPFLAGS+= -D__powerpc__
+OP_CFLAGS+= -fno-section-anchors
 ifdef CONFIG_LINUX_USER
 BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
 endif
--- qemu-0.9.0.cvs/target-alpha/op_template.h.mm	2007-08-22 03:17:57.000000000 +0000
+++ qemu-0.9.0.cvs/target-alpha/op_template.h	2007-08-22 03:15:49.000000000 +0000
@@ -28,7 +28,26 @@ void OPPROTO glue(op_reset_T, REG) (void
 
 void OPPROTO glue(op_reset_FT, REG) (void)
 {
+#ifdef HOST_PPC
+    /* We have a problem with HOST_PPC here:
+       We want this code:
+         glue(FT, REG) = 0;
+       unfortunately GCC4 notices that this stores (double)0.0 into
+       env->ft0 and emits that constant into the .rodata, and instructions
+       to load that zero from there.  But that construct can't be parsed by dyngen.
+       We could add -ffast-math for compiling op.c, that would just make it generate
+       two stores of zeros into both words of ft0.  But -ffast-math may have other
+       side-effects regarding the emulation.  We could use __builtin_memset,
+       which perhaps would be the sanest.  That relies on -O2 and our other options
+       to inline that memset, which currently it does, but who knows for how long.
+       So, we simply do that by hand, and a barely typesafe way :-/  */
+    union baeh { double d; unsigned int i[2];};
+    union baeh *p = (union baeh*)&(glue(FT, REG));
+    p->i[0] = 0;
+    p->i[1] = 0;
+#else
     glue(FT, REG) = 0;
+#endif
     RETURN();
 }
 

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Andreas Färber]

Hi Michael,

Am 28.08.2007 um 21:57 schrieb Michael Matz:

> the below patch let's qemu be compiled by GCC 4.2

Thanks for your effort!

> Here's some justification
>        of why that doesn't really cost performance: with three free  
> regs
>        GCC is already spilling like mad in the snippets, we just  
> trade one
>        of those memory accesses (to stack) with one other mem  
> access to
>        the cpu_state structure, which will be in cache.
>
>        Additionally I made sure that I put the least used Tx global  
> into
>        memory.  I haven't done much performance measurements but  
> noticed
>        no glaring problems.

Am I right to assume that compiling with gcc3 will still work with  
your patch? In that case your patch would enable qemu to run on gcc4- 
only platforms (where performance doesn't matter too much yet) while  
allowing to compile with gcc3 for performance reasons where necessary.

> The whole patch is against a 0.9.0-cvs version from 2007-07-09  
> (Alex might
> know the exact checkout date), so chances are that it still applies :)

What do you mean with 0.9.0-cvs? The 0.9.0 GCC4 patches for OSX/Intel  
don't apply to HEAD possibly due to some inline assembler changes,  
and if merged manually resulted in a crash...

Andreas

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1578 bytes --]

Hi,

On Tue, 28 Aug 2007, Michael Matz wrote:

> The whole patch is against a 0.9.0-cvs version from 2007-07-09 (Alex 
> might know the exact checkout date), so chances are that it still 
> applies :)

It is based on the z80 fork, but it applies relatively cleanly (one 
trailing whitespace) to the version as of "Use unsigned 32-bit load for 
ld/lduw".

However, I still get this error:

../dyngen -o op.h op.o
dyngen: ret or jmp expected at the end of op_tadd_T1_T0_ccTV
make[1]: *** [op.h] Fehler 1
make[1]: Leaving directory `/home/me/qemu/sparc-linux-user'

When only making i386-softmmu, I still get this (on SuSE 10.2):

In file included from /home/gene099/my/qemu/usb-linux.c:29:
/usr/include/linux/usbdevice_fs.h:49: error: expected ‘:’, ‘,’, ‘;’, ‘}’ 
or ‘__attribute__’ before ‘*’ token
/usr/include/linux/usbdevice_fs.h:56: error: expected ‘:’, ‘,’, ‘;’, ‘}’ 
or ‘__attribute__’ before ‘*’ token
/usr/include/linux/usbdevice_fs.h:66: error: expected ‘:’, ‘,’, ‘;’, ‘}’ 
or ‘__attribute__’ before ‘*’ token
/usr/include/linux/usbdevice_fs.h:100: error: expected ‘:’, ‘,’, ‘;’, ‘}’ 
or ‘__attribute__’ before ‘*’ token
/usr/include/linux/usbdevice_fs.h:116: error: expected ‘:’, ‘,’, ‘;’, ‘}’ 
or ‘__attribute__’ before ‘*’ token
/home/me/qemu/usb-linux.c: In function ‘usb_host_handle_data’:
/home/me/qemu/usb-linux.c:130: error: ‘struct 
usbdevfs_bulktransfer’ has no member named ‘data’
make: *** [usb-linux.o] Fehler 1

Ciao,
Dscho

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Michael Matz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1402 bytes --]

Hi,

On Wed, 29 Aug 2007, Andreas Färber wrote:

> Am I right to assume that compiling with gcc3 will still work with your 
> patch?

Yes.

> In that case your patch would enable qemu to run on gcc4-only platforms 
> (where performance doesn't matter too much yet) while allowing to 
> compile with gcc3 for performance reasons where necessary.

If necessary yes.  The patch obviously would need to be changed to be 
conditional not only on HOST_I386 but also on GCC version.  Better to do 
benchmarks first, if it's worthwhile.

> >The whole patch is against a 0.9.0-cvs version from 2007-07-09 (Alex 
> >might know the exact checkout date), so chances are that it still 
> >applies :)
> 
> What do you mean with 0.9.0-cvs? The 0.9.0 GCC4 patches for OSX/Intel 

Do you mean my patches?

> don't apply to HEAD possibly due to some inline assembler changes,

It seems target-z80 doesn't exist in CVS, apart from that there's a small 
s/target_ulong/ppc_gpr_t/ in the target-ppc hunk.  Otherwise it applies 
just fine (I'll attach the patch against CVS, in case pine managed to 
mangle it last time).

> and if merged manually resulted in a crash...

I just tested the attached patch with qemu fresh from CVS on HOST_I386 
with target i386 (no kqemu, so it's really emulating), and target mipsel.
It works just fine.  (gcc 4.1.2 for that matter)


Ciao,
Michael.

[-- Attachment #2: Type: TEXT/x-patch, Size: 9794 bytes --]

Index: Makefile.target
===================================================================
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.194
diff -u -p -r1.194 Makefile.target
--- Makefile.target	26 Aug 2007 17:45:59 -0000	1.194
+++ Makefile.target	29 Aug 2007 10:29:42 -0000
@@ -125,6 +125,7 @@ endif
 
 ifeq ($(ARCH),ppc)
 CPPFLAGS+= -D__powerpc__
+OP_CFLAGS+= -fno-section-anchors
 ifdef CONFIG_LINUX_USER
 BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
 endif
Index: softmmu_header.h
===================================================================
RCS file: /sources/qemu/qemu/softmmu_header.h,v
retrieving revision 1.15
diff -u -p -r1.15 softmmu_header.h
--- softmmu_header.h	23 May 2007 19:58:10 -0000	1.15
+++ softmmu_header.h	29 Aug 2007 10:29:42 -0000
@@ -250,14 +250,18 @@ static inline void glue(glue(st, SUFFIX)
                   : "r" (ptr), 
 /* NOTE: 'q' would be needed as constraint, but we could not use it
    with T1 ! */
+#if DATA_SIZE == 1 || DATA_SIZE == 2
+		  "q" (v),
+#else
                   "r" (v), 
+#endif
                   "i" ((CPU_TLB_SIZE - 1) << CPU_TLB_ENTRY_BITS), 
                   "i" (TARGET_PAGE_BITS - CPU_TLB_ENTRY_BITS), 
                   "i" (TARGET_PAGE_MASK | (DATA_SIZE - 1)),
                   "m" (*(uint32_t *)offsetof(CPUState, tlb_table[CPU_MEM_INDEX][0].addr_write)),
                   "i" (CPU_MEM_INDEX),
                   "m" (*(uint8_t *)&glue(glue(__st, SUFFIX), MMUSUFFIX))
-                  : "%eax", "%ecx", "%edx", "memory", "cc");
+                  : "%eax", "%edx", "memory", "cc");
 }
 
 #else
Index: target-alpha/cpu.h
===================================================================
RCS file: /sources/qemu/qemu/target-alpha/cpu.h,v
retrieving revision 1.4
diff -u -p -r1.4 cpu.h
--- target-alpha/cpu.h	3 Jun 2007 21:02:37 -0000	1.4
+++ target-alpha/cpu.h	29 Aug 2007 10:29:43 -0000
@@ -278,6 +278,8 @@ struct CPUAlphaState {
      * used to emulate 64 bits target on 32 bits hosts
      */ 
     target_ulong t0, t1, t2;
+#elif defined(HOST_I386)
+    target_ulong t2;
 #endif
     /* */
     double ft0, ft1, ft2;
Index: target-alpha/exec.h
===================================================================
RCS file: /sources/qemu/qemu/target-alpha/exec.h,v
retrieving revision 1.2
diff -u -p -r1.2 exec.h
--- target-alpha/exec.h	3 Jun 2007 17:44:36 -0000	1.2
+++ target-alpha/exec.h	29 Aug 2007 10:29:43 -0000
@@ -40,7 +40,11 @@ register struct CPUAlphaState *env asm(A
 
 register uint64_t T0 asm(AREG1);
 register uint64_t T1 asm(AREG2);
+#ifndef HOST_I386
 register uint64_t T2 asm(AREG3);
+#else
+#define T2 (env->t2)
+#endif
 
 #endif /* TARGET_LONG_BITS > HOST_LONG_BITS */
 
Index: target-alpha/op_template.h
===================================================================
RCS file: /sources/qemu/qemu/target-alpha/op_template.h,v
retrieving revision 1.1
diff -u -p -r1.1 op_template.h
--- target-alpha/op_template.h	5 Apr 2007 06:58:33 -0000	1.1
+++ target-alpha/op_template.h	29 Aug 2007 10:29:43 -0000
@@ -28,7 +28,26 @@ void OPPROTO glue(op_reset_T, REG) (void
 
 void OPPROTO glue(op_reset_FT, REG) (void)
 {
+#ifdef HOST_PPC
+    /* We have a problem with HOST_PPC here:
+       We want this code:
+         glue(FT, REG) = 0;
+       unfortunately GCC4 notices that this stores (double)0.0 into
+       env->ft0 and emits that constant into the .rodata, and instructions
+       to load that zero from there.  But that construct can't be parsed by dyngen.
+       We could add -ffast-math for compiling op.c, that would just make it generate
+       two stores of zeros into both words of ft0.  But -ffast-math may have other
+       side-effects regarding the emulation.  We could use __builtin_memset,
+       which perhaps would be the sanest.  That relies on -O2 and our other options
+       to inline that memset, which currently it does, but who knows for how long.
+       So, we simply do that by hand, and a barely typesafe way :-/  */
+    union baeh { double d; unsigned int i[2];};
+    union baeh *p = (union baeh*)&(glue(FT, REG));
+    p->i[0] = 0;
+    p->i[1] = 0;
+#else
     glue(FT, REG) = 0;
+#endif
     RETURN();
 }
 
Index: target-arm/cpu.h
===================================================================
RCS file: /sources/qemu/qemu/target-arm/cpu.h,v
retrieving revision 1.30
diff -u -p -r1.30 cpu.h
--- target-arm/cpu.h	29 Jul 2007 17:57:26 -0000	1.30
+++ target-arm/cpu.h	29 Aug 2007 10:29:43 -0000
@@ -52,6 +52,9 @@ typedef uint32_t ARMReadCPFunc(void *opa
  */
 
 typedef struct CPUARMState {
+#if defined(HOST_I386)
+    uint32_t t1;
+#endif
     /* Regs for current mode.  */
     uint32_t regs[16];
     /* Frequently accessed CPSR bits are stored separately for efficiently.
Index: target-arm/exec.h
===================================================================
RCS file: /sources/qemu/qemu/target-arm/exec.h,v
retrieving revision 1.12
diff -u -p -r1.12 exec.h
--- target-arm/exec.h	3 Jun 2007 17:44:36 -0000	1.12
+++ target-arm/exec.h	29 Aug 2007 10:29:43 -0000
@@ -23,7 +23,12 @@
 register struct CPUARMState *env asm(AREG0);
 register uint32_t T0 asm(AREG1);
 register uint32_t T1 asm(AREG2);
+#ifndef HOST_I386
 register uint32_t T2 asm(AREG3);
+#else
+#define T2 (env->t1)
+#endif
+
 
 /* TODO: Put these in FP regs on targets that have such things.  */
 /* It is ok for FT0s and FT0d to overlap.  Likewise FT1s and FT1d.  */
Index: target-i386/cpu.h
===================================================================
RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
retrieving revision 1.45
diff -u -p -r1.45 cpu.h
--- target-i386/cpu.h	11 Jul 2007 22:48:58 -0000	1.45
+++ target-i386/cpu.h	29 Aug 2007 10:29:43 -0000
@@ -427,6 +427,8 @@ typedef struct CPUX86State {
 #if TARGET_LONG_BITS > HOST_LONG_BITS
     /* temporaries if we cannot store them in host registers */
     target_ulong t0, t1, t2;
+#elif defined(HOST_I386)
+    target_ulong t1;
 #endif
 
     /* standard registers */
Index: target-i386/exec.h
===================================================================
RCS file: /sources/qemu/qemu/target-i386/exec.h,v
retrieving revision 1.34
diff -u -p -r1.34 exec.h
--- target-i386/exec.h	26 Jun 2007 08:35:18 -0000	1.34
+++ target-i386/exec.h	29 Aug 2007 10:29:43 -0000
@@ -44,7 +44,11 @@ register struct CPUX86State *env asm(ARE
 /* XXX: use unsigned long instead of target_ulong - better code will
    be generated for 64 bit CPUs */
 register target_ulong T0 asm(AREG1);
+#ifndef HOST_I386
 register target_ulong T1 asm(AREG2);
+#else
+#define T1 (env->t1)
+#endif
 register target_ulong T2 asm(AREG3);
 
 /* if more registers are available, we define some registers too */
Index: target-mips/cpu.h
===================================================================
RCS file: /sources/qemu/qemu/target-mips/cpu.h,v
retrieving revision 1.42
diff -u -p -r1.42 cpu.h
--- target-mips/cpu.h	23 Jun 2007 18:04:11 -0000	1.42
+++ target-mips/cpu.h	29 Aug 2007 10:29:43 -0000
@@ -60,7 +60,10 @@ struct CPUMIPSState {
     target_ulong t0;
     target_ulong t1;
     target_ulong t2;
+#elif defined(HOST_I386)
+    target_ulong t1;
 #endif
+    
     target_ulong HI, LO;
     /* Floating point registers */
     fpr_t fpr[32];
Index: target-mips/exec.h
===================================================================
RCS file: /sources/qemu/qemu/target-mips/exec.h,v
retrieving revision 1.30
diff -u -p -r1.30 exec.h
--- target-mips/exec.h	3 Jun 2007 17:44:36 -0000	1.30
+++ target-mips/exec.h	29 Aug 2007 10:29:43 -0000
@@ -17,7 +17,11 @@ register struct CPUMIPSState *env asm(AR
 #else
 register target_ulong T0 asm(AREG1);
 register target_ulong T1 asm(AREG2);
+#ifndef HOST_I386
 register target_ulong T2 asm(AREG3);
+#else
+#define T2 (env->t1)
+#endif
 #endif
 
 #if defined (USE_HOST_FLOAT_REGS)
Index: target-ppc/cpu.h
===================================================================
RCS file: /sources/qemu/qemu/target-ppc/cpu.h,v
retrieving revision 1.49
diff -u -p -r1.49 cpu.h
--- target-ppc/cpu.h	11 Jul 2007 10:36:47 -0000	1.49
+++ target-ppc/cpu.h	29 Aug 2007 10:29:43 -0000
@@ -694,6 +694,8 @@ struct CPUPPCState {
      * used to emulate 64 bits target on 32 bits hosts
      */ 
     ppc_gpr_t t0, t1, t2;
+#elif defined(HOST_I386)
+    ppc_gpr_t t1;
 #endif
     ppc_avr_t t0_avr, t1_avr, t2_avr;
 
Index: target-ppc/exec.h
===================================================================
RCS file: /sources/qemu/qemu/target-ppc/exec.h,v
retrieving revision 1.22
diff -u -p -r1.22 exec.h
--- target-ppc/exec.h	11 Jul 2007 10:36:47 -0000	1.22
+++ target-ppc/exec.h	29 Aug 2007 10:29:43 -0000
@@ -40,7 +40,11 @@ register struct CPUPPCState *env asm(ARE
 #else
 register unsigned long T0 asm(AREG1);
 register unsigned long T1 asm(AREG2);
+#ifndef HOST_I386
 register unsigned long T2 asm(AREG3);
+#else
+#define T2 (env->t1)
+#endif
 #endif
 /* We may, sometime, need 64 bits registers on 32 bits target */
 #if TARGET_GPR_BITS > HOST_LONG_BITS
Index: target-sparc/exec.h
===================================================================
RCS file: /sources/qemu/qemu/target-sparc/exec.h,v
retrieving revision 1.19
diff -u -p -r1.19 exec.h
--- target-sparc/exec.h	3 Jun 2007 17:44:37 -0000	1.19
+++ target-sparc/exec.h	29 Aug 2007 10:29:43 -0000
@@ -32,9 +32,13 @@ register uint32_t T2 asm(AREG4);
 
 #else
 #define REGWPTR env->regwptr
+#ifndef HOST_I386
 register uint32_t T2 asm(AREG3);
-#endif
 #define reg_T2
+#else
+#define T2 (env->t2)
+#endif
+#endif
 #endif
 
 #define FT0 (env->ft0)

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Michael Matz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2601 bytes --]

Hi,

On Wed, 29 Aug 2007, Johannes Schindelin wrote:

> > The whole patch is against a 0.9.0-cvs version from 2007-07-09 (Alex 
> > might know the exact checkout date), so chances are that it still 
> > applies :)
> 
> It is based on the z80 fork, but it applies relatively cleanly (one 
> trailing whitespace) to the version as of "Use unsigned 32-bit load for 
> ld/lduw".
> 
> However, I still get this error:
> 
> ../dyngen -o op.h op.o
> dyngen: ret or jmp expected at the end of op_tadd_T1_T0_ccTV
> make[1]: *** [op.h] Fehler 1
> make[1]: Leaving directory `/home/me/qemu/sparc-linux-user'

Using SuSE 10.2, i.e. gcc 4.1.2?  For qemu CVS (see my other mail) I 
didn't test linux-user at all.  In our qemu package itself (which builds 
also the linux-user parts) there are some more patches which might fix the 
above problem, don't know yet.  I would try --disable-linux-user in your 
case.  I can look at it later.

> 
> When only making i386-softmmu, I still get this (on SuSE 10.2):
> 
> In file included from /home/gene099/my/qemu/usb-linux.c:29:
> /usr/include/linux/usbdevice_fs.h:49: error: expected ‘:’, ‘,’, ‘;’, ‘}’ 
> or ‘__attribute__’ before ‘*’ token
> /usr/include/linux/usbdevice_fs.h:56: error: expected ‘:’, ‘,’, ‘;’, ‘}’ 
> or ‘__attribute__’ before ‘*’ token
> /usr/include/linux/usbdevice_fs.h:66: error: expected ‘:’, ‘,’, ‘;’, ‘}’ 
> or ‘__attribute__’ before ‘*’ token
> /usr/include/linux/usbdevice_fs.h:100: error: expected ‘:’, ‘,’, ‘;’, ‘}’ 
> or ‘__attribute__’ before ‘*’ token
> /usr/include/linux/usbdevice_fs.h:116: error: expected ‘:’, ‘,’, ‘;’, ‘}’ 
> or ‘__attribute__’ before ‘*’ token
> /home/me/qemu/usb-linux.c: In function ‘usb_host_handle_data’:
> /home/me/qemu/usb-linux.c:130: error: ‘struct 
> usbdevfs_bulktransfer’ has no member named ‘data’
> make: *** [usb-linux.o] Fehler 1

Yes, that's a problem of the kernel headers on 10.2.  You can work around 
this with the below snippet.


Ciao,
Michael.
-- 
Index: usb-linux.c
===================================================================
RCS file: /sources/qemu/qemu/usb-linux.c,v
retrieving revision 1.10
diff -u -p -r1.10 usb-linux.c
--- usb-linux.c 10 Dec 2006 22:11:04 -0000      1.10
+++ usb-linux.c 29 Aug 2007 11:45:13 -0000
@@ -26,6 +26,7 @@
 #if defined(__linux__)
 #include <dirent.h>
 #include <sys/ioctl.h>
+#define __user
 #include <linux/usbdevice_fs.h>
 #include <linux/version.h>

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1618 bytes --]

Hi,

On Wed, 29 Aug 2007, Michael Matz wrote:

> On Wed, 29 Aug 2007, Johannes Schindelin wrote:
> 
> > > The whole patch is against a 0.9.0-cvs version from 2007-07-09 (Alex 
> > > might know the exact checkout date), so chances are that it still 
> > > applies :)
> > 
> > It is based on the z80 fork, but it applies relatively cleanly (one 
> > trailing whitespace) to the version as of "Use unsigned 32-bit load 
> > for ld/lduw".
> > 
> > However, I still get this error:
> > 
> > ../dyngen -o op.h op.o
> > dyngen: ret or jmp expected at the end of op_tadd_T1_T0_ccTV
> > make[1]: *** [op.h] Fehler 1
> > make[1]: Leaving directory `/home/me/qemu/sparc-linux-user'
> 
> Using SuSE 10.2, i.e. gcc 4.1.2?

Yep.  It would be good to fix this error before applying the patch to CVS 
;-)

> > When only making i386-softmmu, I still get this (on SuSE 10.2):
> > 
> > In file included from /home/gene099/my/qemu/usb-linux.c:29:
> > /usr/include/linux/usbdevice_fs.h:49: error: expected ‘:’, ‘,’, ‘;’, ‘}’ 
> > or ‘__attribute__’ before ‘*’ token
> > [...]
> 
> Yes, that's a problem of the kernel headers on 10.2.  You can work 
> around this with the below snippet.

I did it differently now.

My changes can be seen (and fetched) at

	http://repo.or.cz/qemu/dscho.git/

in the "gcc4" branch.  This is just your patch applied to the revision I 
mentioned (which is available in the "gcc4-original" branch), then rebased 
onto current CVS (or what Jens Axboe's clone is current at right now).  I 
adjusted one target_ulong, and added another commit for the 
linux/compiler.h issue.

Ciao,
Dscho

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Andreas Färber]

Am 29.08.2007 um 13:40 schrieb Michael Matz:

>>> The whole patch is against a 0.9.0-cvs version from 2007-07-09 (Alex
>>> might know the exact checkout date), so chances are that it still
>>> applies :)
>>
>> What do you mean with 0.9.0-cvs? The 0.9.0 GCC4 patches for OSX/Intel
>
> Do you mean my patches?

No. Are yours already OSX-compatible? I referred to previous patches,  
specifically those currently applied for Q:
http://www.kju-app.org/proj/browser/trunk/patches
There were also some in the QEMU forums. Those only apply to the  
0.9.0 tag.

So I was wondering whether 0.9.0-cvs from date meant 0.9.0 tag or  
HEAD as of date. Sorry if this is obvious but I'm used to Subversion.  
In your patch I first read qemu-0.9.0, which confused me as I don't  
consider CVS HEAD to be 0.9.0. Will try your updated patch later.

Best regards,

Andreas

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Michael Matz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1438 bytes --]

Hi,

On Wed, 29 Aug 2007, Andreas Färber wrote:

> > >What do you mean with 0.9.0-cvs? The 0.9.0 GCC4 patches for OSX/Intel
> >
> >Do you mean my patches?
> 
> No. Are yours already OSX-compatible?

No OSX, no idea :)

> I referred to previous patches, specifically those currently applied for 
> Q: http://www.kju-app.org/proj/browser/trunk/patches There were also 
> some in the QEMU forums. Those only apply to the 0.9.0 tag.

I see.  We seem to use some of these patches (perhaps in a modified form) 
in our qemu package too.  Sorry that I'm so unsure about the qemu topics, 
I'm only a compiler developer hitting qemu hard enough until it works with 
gcc4 :-)

> So I was wondering whether 0.9.0-cvs from date meant 0.9.0 tag or HEAD 
> as of date.

It was supposed to mean some CVS checkout from after 0.9.0 release, where 
I myself couldn't really make out at which date the checkout was done 
(because it wasn't done by me, and I didn't feel like digging too long, as 
the patch obviously still applied mostly).

> Sorry if this is obvious but I'm used to Subversion. In your patch I 
> first read qemu-0.9.0, which confused me as I don't consider CVS HEAD to 
> be 0.9.0. Will try your updated patch later.

That btw. is against CVS HEAD (as of today).  I have no idea what's 
necessary for OSX, it might be that you need additional patches, or not, 
can't help with that.


Ciao,
Michael.

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Johannes Schindelin]

Hi,

On Wed, 29 Aug 2007, Andreas F?rber wrote:

> I referred to previous patches, specifically those currently applied for 
> Q: http://www.kju-app.org/proj/browser/trunk/patches

Is there _any_ way to get at the raw diffs instead of some @!%! marked up 
HTML abomination that cannot be applied?

Ciao,
Dscho

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Mulyadi Santosa]

Hi ...

Thanks for your effor Michael! Now, I only hope, one of the patches that 
makes qemu gcc4 compliant are soon merged. Or, is there any plan to 
merge qops?

regards,

Mulyadi

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Johannes Schindelin]

Hi,

On Wed, 29 Aug 2007, Mulyadi Santosa wrote:

> Thanks for your effor Michael! Now, I only hope, one of the patches that
> makes qemu gcc4 compliant are soon merged.

Well, to throw a spanner in the works: this patch is the 4th patch along 
the lines that I came about.  None of them (AFAICT) was tested well enough 
to be included in CVS.  Indeed, the biggest problem seems to be to make a 
patch that not only works on the machine of the poster, but on other 
machines, too.

> Or, is there any plan to merge qops?

I was pretty enthusiastic about qops a while ago.  But then I saw that 
they hurt performance.  And performance is the primary reason I use QEmu, 
so I am not at all convinced that this is the way to go.  Even if parts 
have been merged already.

Ciao,
Dscho

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Ronald]

Johannes Schindelin schreef:
> Hi,
>
> On Wed, 29 Aug 2007, Andreas F?rber wrote:
>
>   
>> I referred to previous patches, specifically those currently applied for 
>> Q: http://www.kju-app.org/proj/browser/trunk/patches
>>     
>
> Is there _any_ way to get at the raw diffs instead of some @!%! marked up 
> HTML abomination that cannot be applied?
>
> Ciao,
> Dscho
>
>
>
>
>   
Click a link to a patch and check below the page:


      Download in other formats:

    * Plain Text
      <http://www.kju-app.org/proj/browser/trunk/patches/q_block.c_hdled_1.diff?format=txt>
    * Original Format
      <http://www.kju-app.org/proj/browser/trunk/patches/q_block.c_hdled_1.diff?format=raw>

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Johannes Schindelin]

Hi,

On Wed, 29 Aug 2007, Ronald wrote:

> Johannes Schindelin schreef:
> 
> > On Wed, 29 Aug 2007, Andreas F?rber wrote:
> >   
> > > I referred to previous patches, specifically those currently applied 
> > > for Q: http://www.kju-app.org/proj/browser/trunk/patches
> > 
> > Is there _any_ way to get at the raw diffs instead of some @!%! marked 
> > up HTML abomination that cannot be applied?
>   
> Click a link to a patch and check below the page:

Thanks.  Somehow that slipped by me.

I'll try to put them on my repo.or.cz repository, too.

Ciao,
Dscho

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Andreas Färber]

Hi,

Am 29.08.2007 um 15:59 schrieb Johannes Schindelin:

>> I referred to previous patches, specifically those currently  
>> applied for
>> Q: http://www.kju-app.org/proj/browser/trunk/patches
>
> Is there _any_ way to get at the raw diffs instead of some @!%!  
> marked up
> HTML abomination that cannot be applied?

There's a download link at the bottom of each HTML page. Or  
alternatively check the relevant files out via anonymous SVN.

For applying them have a look at the ../build_i386.sh script and note  
that the script is simple and does not handle patch errors so needs  
to be changed to use.

Andreas

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Andreas Färber]

Am 29.08.2007 um 16:19 schrieb Johannes Schindelin:

>>>> I referred to previous patches, specifically those currently  
>>>> applied
>>>> for Q: http://www.kju-app.org/proj/browser/trunk/patches
>
> I'll try to put them on my repo.or.cz repository, too.

Note that from briefly looking at them they appear to contain some  
permanent changes, i.e. some of them should probably only be applied  
on the respective platform itself.

Regards,
Andreas

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Paul Brook]

>        I solved that by placing one of the T[012] operands into memory
>        for HOST_I386, thereby freeing one reg.  Here's some justification
>        of why that doesn't really cost performance: with three free regs
>        GCC is already spilling like mad in the snippets, we just trade one
>        of those memory accesses (to stack) with one other mem access to
>        the cpu_state structure, which will be in cache.

Do you have any evidence to support this claim? Last time I did this it caused 
a significant performance hit. I'd guess that most common ops are simple 
enough that we don't need more than 3 registers.

> --- qemu-0.9.0.cvs.orig/softmmu_header.h
> -                  : "%eax", "%ecx", "%edx", "memory", "cc");
> +                  : "%eax", "%edx", "memory", "cc");

This change is wrong. The inline asm calls C code which clobbers %ecx.

Paul

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Michael Matz]

Hi,

On Wed, 29 Aug 2007, Johannes Schindelin wrote:

> > Thanks for your effor Michael! Now, I only hope, one of the patches 
> > that makes qemu gcc4 compliant are soon merged.
> 
> Well, to throw a spanner in the works: this patch is the 4th patch along 
> the lines that I came about.  None of them (AFAICT) was tested well 
> enough to be included in CVS.  Indeed, the biggest problem seems to be 
> to make a patch that not only works on the machine of the poster, but on 
> other machines, too.

Please?  qemu with that patch builds on four architectures, and tests fine 
on two of them (including cross targets) and only because I haven't run it 
on the other two architectures yet.  It might or might not need more 
patches than just mine (as I started from our package), but in that case 
they are independend of making qemu work with gcc 4, which is the only 
thing my patch is concerned about.


Ciao,
Michael.

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Johannes Schindelin]

Hi,

On Wed, 29 Aug 2007, Michael Matz wrote:

> On Wed, 29 Aug 2007, Johannes Schindelin wrote:
> 
> > > Thanks for your effor Michael! Now, I only hope, one of the patches 
> > > that makes qemu gcc4 compliant are soon merged.
> > 
> > Well, to throw a spanner in the works: this patch is the 4th patch along 
> > the lines that I came about.  None of them (AFAICT) was tested well 
> > enough to be included in CVS.  Indeed, the biggest problem seems to be 
> > to make a patch that not only works on the machine of the poster, but on 
> > other machines, too.
> 
> Please?  qemu with that patch builds on four architectures, and tests 
> fine on two of them (including cross targets) and only because I haven't 
> run it on the other two architectures yet.

Hey, I am not criticising you!  Instead, I am thankful enough that I went 
so far as to expose it with git.

> It might or might not need more patches than just mine (as I started 
> from our package), but in that case they are independend of making qemu 
> work with gcc 4, which is the only thing my patch is concerned about.

I already reported the non-compiling state of sparc-linux-user...  Any 
idea what I could do about it?

Ciao,
Dscho

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Michael Matz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3907 bytes --]

Hi,

On Wed, 29 Aug 2007, Paul Brook wrote:

> >        I solved that by placing one of the T[012] operands into memory
> >        for HOST_I386, thereby freeing one reg.  Here's some justification
> >        of why that doesn't really cost performance: with three free regs
> >        GCC is already spilling like mad in the snippets, we just trade one
> >        of those memory accesses (to stack) with one other mem access to
> >        the cpu_state structure, which will be in cache.
> 
> Do you have any evidence to support this claim?

Not really, only an apple and orange comparison.  A 10000 iteration 
tests/sha1 run in the same Linux image, with -no-kqemu, on host and target 
i386:  time ./sha1

with qemu-0.8.2 (compiled by gcc 3.3-hammer): 7.92 seconds
with qemu-0.9.0-cvs (gcc4.1 compiled, with the patch): 8.15 seconds

I'll try to get a better comparison.  Note, though, that this is the only 
easy solution.  Any other solution would either involve improving reload 
pretty much, or rewriting many of the op.c patterns (for all targets) to 
never require more than three registers, and ensure that gcc doesn't 
become clever and mashes some insns together again (and in trying to do 
that probably slow down the snippets again).  Or doing away with dyngen at 
all.  All three solutions are fairly involved, so I'm personally fine with 
the above slowdown (for i386 targets you won't normally get any noticable 
slowdown as you'd use kqemu).

> Last time I did this it caused a significant performance hit. I'd guess 
> that most common ops are simple enough that we don't need more than 3 
> registers.

For i386 target I'm redefining only T1 (as I figured that A0 and T0 are 
used a bit more), it might be that some of the code could be generated in 
a way to not make use of T1 too much, I haven't really poked at that.

> > --- qemu-0.9.0.cvs.orig/softmmu_header.h
> > -                  : "%eax", "%ecx", "%edx", "memory", "cc");
> > +                  : "%eax", "%edx", "memory", "cc");
> 
> This change is wrong. The inline asm calls C code which clobbers %ecx.

Indeed, must have been blind.  Okay these are too many clobbers for poor 
gcc4 nevertheless, so a push/pop %ecx around the call needs to be done.  
Courious that this didn't lead to fire all over the place.  See patch 
below.


Ciao,
Michael.

Index: softmmu_header.h
===================================================================
RCS file: /sources/qemu/qemu/softmmu_header.h,v
retrieving revision 1.15
diff -u -p -r1.15 softmmu_header.h
--- softmmu_header.h	23 May 2007 19:58:10 -0000	1.15
+++ softmmu_header.h	29 Aug 2007 17:27:37 -0000
@@ -230,9 +230,11 @@ static inline void glue(glue(st, SUFFIX)
 #else
 #error unsupported size
 #endif
+		  "pushl %%ecx\n"
                   "pushl %6\n"
                   "call %7\n"
                   "popl %%eax\n"
+                  "popl %%ecx\n"
                   "jmp 2f\n"
                   "1:\n"
                   "addl 8(%%edx), %%eax\n"
@@ -250,14 +252,18 @@ static inline void glue(glue(st, SUFFIX)
                   : "r" (ptr), 
 /* NOTE: 'q' would be needed as constraint, but we could not use it
    with T1 ! */
+#if DATA_SIZE == 1 || DATA_SIZE == 2
+		  "q" (v),
+#else
                   "r" (v), 
+#endif
                   "i" ((CPU_TLB_SIZE - 1) << CPU_TLB_ENTRY_BITS), 
                   "i" (TARGET_PAGE_BITS - CPU_TLB_ENTRY_BITS), 
                   "i" (TARGET_PAGE_MASK | (DATA_SIZE - 1)),
                   "m" (*(uint32_t *)offsetof(CPUState, tlb_table[CPU_MEM_INDEX][0].addr_write)),
                   "i" (CPU_MEM_INDEX),
                   "m" (*(uint8_t *)&glue(glue(__st, SUFFIX), MMUSUFFIX))
-                  : "%eax", "%ecx", "%edx", "memory", "cc");
+                  : "%eax", "%edx", "memory", "cc");
 }
 
 #else

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Anthony Liguori]

On Tue, 2007-08-28 at 21:57 +0200, Michael Matz wrote:
> Hi,
> 
> [please keep me CCed, I'm not on this list]
> 
> the below patch let's qemu be compiled by GCC 4.2 (probably also 4.1 and 
> others) for most hosts (i386,x86_64,ia64,ppc).  s390 as host is missing, 
> and needs a compiler change to emit the literal store inline again, as the 
> literal pool at the end fundamentally breaks the assumption that qemu can 
> paste together the code snippets by patching out the return.  I have no 
> HOST_{ARM,MIPS*,ALPHA,SPARC*,M68K} machines to compile for that.

There have been similar patches to this.  While QEMU will compile,
dyngen still will generate invalid code due to ret's in the middle of
translation blocks.  Your patch doesn't seem to address this.  How do
you cope with this?

Regards,

Anthony Liguori

> It specifically changes these things:
> 
> * ppc: adds -fno-section-anchors to OP_CFLAGS, as dyngen isn't prepared
>        to deal with the relocs resulting from using section anchors
> * ppc: on target-alpha op_reset_FT GCC4 uses a floating point constant 0.0
>        to reset the ft regs, which in turn is loaded from the data 
>        section.  The reloc for that is unhandled.  Using -ffast-math would 
>        work around this, but I chose to be conservative and change only
>        the op.c snippet in question.  See the comment there.
> * i386: well, most of you will know that GCC4 doesn't compile qemu because 
>        of reload.  The inherent problem is, that qemu uses 64bit
>        entities in some places (sometimes structs), which GCC (4.x) 
>        manages to place in registers, i.e. needs 2 hardregs.  But it 
>        sometimes just so happens that an instruction needing such DImode
>        reg also has a memory operand with an indexed address (reg plus 
>        reg), hence two hardregs more.  But qemu by default leaves just 
>        three free registers for compiling op.c --> boom.  This is somewhat 
>        hard to work around in GCC (trust me :) ).
> 
>        I solved that by placing one of the T[012] operands into memory
>        for HOST_I386, thereby freeing one reg.  Here's some justification 
>        of why that doesn't really cost performance: with three free regs
>        GCC is already spilling like mad in the snippets, we just trade one
>        of those memory accesses (to stack) with one other mem access to 
>        the cpu_state structure, which will be in cache.
> 
>        Additionally I made sure that I put the least used Tx global into 
>        memory.  I haven't done much performance measurements but noticed 
>        no glaring problems.
> 
>        Two more obvious changes in an inline asm in softmmu_header.h were 
>        necessary too.
> 
> A qemu with that patch was tested on HOST_I386 with all images from the 
> qemu homepage (i.e. arm, mips, mipsel, coldfire (that doesn't work) and 
> sparc), some i386 boot isos and a freedos image.  It also was tested on 
> HOST_X86_64 installing openSUSE beta-something for i386 and x86_64.  I 
> haven't yet tested it on ia64 or ppc hosts.
> 
> The whole patch is against a 0.9.0-cvs version from 2007-07-09 (Alex might 
> know the exact checkout date), so chances are that it still applies :)
> 
> 
> Ciao,
> Michael.
> 
> diff -urp qemu-0.9.0.cvs.orig/softmmu_header.h qemu-0.9.0.cvs/softmmu_header.h
> --- qemu-0.9.0.cvs.orig/softmmu_header.h	2007-08-21 18:58:00.000000000 +0200
> +++ qemu-0.9.0.cvs/softmmu_header.h	2007-08-21 20:40:23.000000000 +0200
> @@ -254,14 +254,18 @@ static inline void glue(glue(st, SUFFIX)
>                    : "r" (ptr), 
>  /* NOTE: 'q' would be needed as constraint, but we could not use it
>     with T1 ! */
> +#if DATA_SIZE == 1 || DATA_SIZE == 2
> +		  "q" (v),
> +#else
>                    "r" (v), 
> +#endif
>                    "i" ((CPU_TLB_SIZE - 1) << CPU_TLB_ENTRY_BITS), 
>                    "i" (TARGET_PAGE_BITS - CPU_TLB_ENTRY_BITS), 
>                    "i" (TARGET_PAGE_MASK | (DATA_SIZE - 1)),
>                    "m" (*(uint32_t *)offsetof(CPUState, tlb_table[CPU_MEM_INDEX][0].addr_write)),
>                    "i" (CPU_MEM_INDEX),
>                    "m" (*(uint8_t *)&glue(glue(__st, SUFFIX), MMUSUFFIX))
> -                  : "%eax", "%ecx", "%edx", "memory", "cc");
> +                  : "%eax", "%edx", "memory", "cc");
>  }
>  
>  #else
> diff -urp qemu-0.9.0.cvs.orig/target-alpha/cpu.h qemu-0.9.0.cvs/target-alpha/cpu.h
> --- qemu-0.9.0.cvs.orig/target-alpha/cpu.h	2007-06-03 23:02:37.000000000 +0200
> +++ qemu-0.9.0.cvs/target-alpha/cpu.h	2007-08-22 00:54:15.000000000 +0200
> @@ -278,6 +278,8 @@ struct CPUAlphaState {
>       * used to emulate 64 bits target on 32 bits hosts
>       */ 
>      target_ulong t0, t1, t2;
> +#elif defined(HOST_I386)
> +    target_ulong t2;
>  #endif
>      /* */
>      double ft0, ft1, ft2;
> diff -urp qemu-0.9.0.cvs.orig/target-alpha/exec.h qemu-0.9.0.cvs/target-alpha/exec.h
> --- qemu-0.9.0.cvs.orig/target-alpha/exec.h	2007-06-03 19:44:36.000000000 +0200
> +++ qemu-0.9.0.cvs/target-alpha/exec.h	2007-08-21 21:28:58.000000000 +0200
> @@ -40,7 +40,11 @@ register struct CPUAlphaState *env asm(A
>  
>  register uint64_t T0 asm(AREG1);
>  register uint64_t T1 asm(AREG2);
> +#ifndef HOST_I386
>  register uint64_t T2 asm(AREG3);
> +#else
> +#define T2 (env->t2)
> +#endif
>  
>  #endif /* TARGET_LONG_BITS > HOST_LONG_BITS */
>  
> diff -urp qemu-0.9.0.cvs.orig/target-arm/cpu.h qemu-0.9.0.cvs/target-arm/cpu.h
> --- qemu-0.9.0.cvs.orig/target-arm/cpu.h	2007-06-24 14:09:48.000000000 +0200
> +++ qemu-0.9.0.cvs/target-arm/cpu.h	2007-08-21 21:38:36.000000000 +0200
> @@ -52,6 +52,9 @@ typedef uint32_t ARMReadCPFunc(void *opa
>   */
>  
>  typedef struct CPUARMState {
> +#if defined(HOST_I386)
> +    uint32_t t1;
> +#endif
>      /* Regs for current mode.  */
>      uint32_t regs[16];
>      /* Frequently accessed CPSR bits are stored separately for efficiently.
> diff -urp qemu-0.9.0.cvs.orig/target-arm/exec.h qemu-0.9.0.cvs/target-arm/exec.h
> --- qemu-0.9.0.cvs.orig/target-arm/exec.h	2007-06-03 19:44:36.000000000 +0200
> +++ qemu-0.9.0.cvs/target-arm/exec.h	2007-08-21 21:48:48.000000000 +0200
> @@ -23,7 +23,12 @@
>  register struct CPUARMState *env asm(AREG0);
>  register uint32_t T0 asm(AREG1);
>  register uint32_t T1 asm(AREG2);
> +#ifndef HOST_I386
>  register uint32_t T2 asm(AREG3);
> +#else
> +#define T2 (env->t1)
> +#endif
> +
>  
>  /* TODO: Put these in FP regs on targets that have such things.  */
>  /* It is ok for FT0s and FT0d to overlap.  Likewise FT1s and FT1d.  */
> diff -urp qemu-0.9.0.cvs.orig/target-i386/cpu.h qemu-0.9.0.cvs/target-i386/cpu.h
> --- qemu-0.9.0.cvs.orig/target-i386/cpu.h	2007-06-03 23:02:37.000000000 +0200
> +++ qemu-0.9.0.cvs/target-i386/cpu.h	2007-08-21 21:16:47.000000000 +0200
> @@ -427,6 +427,8 @@ typedef struct CPUX86State {
>  #if TARGET_LONG_BITS > HOST_LONG_BITS
>      /* temporaries if we cannot store them in host registers */
>      target_ulong t0, t1, t2;
> +#elif defined(HOST_I386)
> +    target_ulong t1;
>  #endif
>  
>      /* standard registers */
> diff -urp qemu-0.9.0.cvs.orig/target-i386/exec.h qemu-0.9.0.cvs/target-i386/exec.h
> --- qemu-0.9.0.cvs.orig/target-i386/exec.h	2007-06-26 10:35:18.000000000 +0200
> +++ qemu-0.9.0.cvs/target-i386/exec.h	2007-08-21 21:30:40.000000000 +0200
> @@ -44,7 +44,11 @@ register struct CPUX86State *env asm(ARE
>  /* XXX: use unsigned long instead of target_ulong - better code will
>     be generated for 64 bit CPUs */
>  register target_ulong T0 asm(AREG1);
> +#ifndef HOST_I386
>  register target_ulong T1 asm(AREG2);
> +#else
> +#define T1 (env->t1)
> +#endif
>  register target_ulong T2 asm(AREG3);
>  
>  /* if more registers are available, we define some registers too */
> diff -urp qemu-0.9.0.cvs.orig/target-mips/cpu.h qemu-0.9.0.cvs/target-mips/cpu.h
> --- qemu-0.9.0.cvs.orig/target-mips/cpu.h	2007-06-23 20:04:11.000000000 +0200
> +++ qemu-0.9.0.cvs/target-mips/cpu.h	2007-08-21 21:17:23.000000000 +0200
> @@ -60,7 +60,10 @@ struct CPUMIPSState {
>      target_ulong t0;
>      target_ulong t1;
>      target_ulong t2;
> +#elif defined(HOST_I386)
> +    target_ulong t1;
>  #endif
> +    
>      target_ulong HI, LO;
>      /* Floating point registers */
>      fpr_t fpr[32];
> diff -urp qemu-0.9.0.cvs.orig/target-mips/exec.h qemu-0.9.0.cvs/target-mips/exec.h
> --- qemu-0.9.0.cvs.orig/target-mips/exec.h	2007-06-03 19:44:36.000000000 +0200
> +++ qemu-0.9.0.cvs/target-mips/exec.h	2007-08-21 21:37:06.000000000 +0200
> @@ -17,7 +17,11 @@ register struct CPUMIPSState *env asm(AR
>  #else
>  register target_ulong T0 asm(AREG1);
>  register target_ulong T1 asm(AREG2);
> +#ifndef HOST_I386
>  register target_ulong T2 asm(AREG3);
> +#else
> +#define T2 (env->t1)
> +#endif
>  #endif
>  
>  #if defined (USE_HOST_FLOAT_REGS)
> diff -urp qemu-0.9.0.cvs.orig/target-ppc/cpu.h qemu-0.9.0.cvs/target-ppc/cpu.h
> --- qemu-0.9.0.cvs.orig/target-ppc/cpu.h	2007-06-23 18:02:43.000000000 +0200
> +++ qemu-0.9.0.cvs/target-ppc/cpu.h	2007-08-21 21:19:57.000000000 +0200
> @@ -694,6 +694,8 @@ struct CPUPPCState {
>       * used to emulate 64 bits target on 32 bits hosts
>       */ 
>      target_ulong t0, t1, t2;
> +#elif defined(HOST_I386)
> +    target_ulong t1;
>  #endif
>      ppc_avr_t t0_avr, t1_avr, t2_avr;
>  
> diff -urp qemu-0.9.0.cvs.orig/target-ppc/exec.h qemu-0.9.0.cvs/target-ppc/exec.h
> --- qemu-0.9.0.cvs.orig/target-ppc/exec.h	2007-06-03 19:44:36.000000000 +0200
> +++ qemu-0.9.0.cvs/target-ppc/exec.h	2007-08-21 21:41:41.000000000 +0200
> @@ -40,7 +40,11 @@ register struct CPUPPCState *env asm(ARE
>  #else
>  register unsigned long T0 asm(AREG1);
>  register unsigned long T1 asm(AREG2);
> +#ifndef HOST_I386
>  register unsigned long T2 asm(AREG3);
> +#else
> +#define T2 (env->t1)
> +#endif
>  #endif
>  /* We may, sometime, need 64 bits registers on 32 bits target */
>  #if defined(TARGET_PPC64) || defined(TARGET_PPCEMB) || (HOST_LONG_BITS == 64)
> diff -urp qemu-0.9.0.cvs.orig/target-sparc/exec.h qemu-0.9.0.cvs/target-sparc/exec.h
> --- qemu-0.9.0.cvs.orig/target-sparc/exec.h	2007-06-03 19:44:37.000000000 +0200
> +++ qemu-0.9.0.cvs/target-sparc/exec.h	2007-08-21 21:26:38.000000000 +0200
> @@ -32,9 +32,13 @@ register uint32_t T2 asm(AREG4);
>  
>  #else
>  #define REGWPTR env->regwptr
> +#ifndef HOST_I386
>  register uint32_t T2 asm(AREG3);
> -#endif
>  #define reg_T2
> +#else
> +#define T2 (env->t2)
> +#endif
> +#endif
>  #endif
>  
>  #define FT0 (env->ft0)
> diff -urp qemu-0.9.0.cvs.orig/target-z80/cpu.h qemu-0.9.0.cvs/target-z80/cpu.h
> --- qemu-0.9.0.cvs.orig/target-z80/cpu.h	2007-08-21 18:58:00.000000000 +0200
> +++ qemu-0.9.0.cvs/target-z80/cpu.h	2007-08-21 21:14:37.000000000 +0200
> @@ -147,6 +147,8 @@ typedef struct CPUZ80State {
>  #if TARGET_LONG_BITS > HOST_LONG_BITS
>      /* temporaries if we cannot store them in host registers */
>      target_ulong t0, t1, t2;
> +#elif defined(HOST_I386)
> +    target_ulong t1;
>  #endif
>  
>      /* Z80 registers */
> diff -urp qemu-0.9.0.cvs.orig/target-z80/exec.h qemu-0.9.0.cvs/target-z80/exec.h
> --- qemu-0.9.0.cvs.orig/target-z80/exec.h	2007-08-21 18:58:00.000000000 +0200
> +++ qemu-0.9.0.cvs/target-z80/exec.h	2007-08-21 21:13:47.000000000 +0200
> @@ -40,7 +40,11 @@ register struct CPUZ80State *env asm(ARE
>  /* XXX: use unsigned long instead of target_ulong - better code will
>     be generated for 64 bit CPUs */
>  register target_ulong T0 asm(AREG1);
> +#ifdef HOST_I386
> +#define T1 (env->t1)
> +#else
>  register target_ulong T1 asm(AREG2);
> +#endif
>  register target_ulong T2 asm(AREG3);
>  
>  /* if more registers are available, we define some registers too */
> --- qemu-0.9.0.cvs.orig/Makefile.target	2007-08-21 18:58:01.000000000 +0200
> +++ qemu-0.9.0.cvs/Makefile.target	2007-08-22 02:02:55.000000000 +0200
> @@ -127,6 +127,7 @@ endif
>  
>  ifeq ($(ARCH),ppc)
>  CPPFLAGS+= -D__powerpc__
> +OP_CFLAGS+= -fno-section-anchors
>  ifdef CONFIG_LINUX_USER
>  BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
>  endif
> --- qemu-0.9.0.cvs/target-alpha/op_template.h.mm	2007-08-22 03:17:57.000000000 +0000
> +++ qemu-0.9.0.cvs/target-alpha/op_template.h	2007-08-22 03:15:49.000000000 +0000
> @@ -28,7 +28,26 @@ void OPPROTO glue(op_reset_T, REG) (void
>  
>  void OPPROTO glue(op_reset_FT, REG) (void)
>  {
> +#ifdef HOST_PPC
> +    /* We have a problem with HOST_PPC here:
> +       We want this code:
> +         glue(FT, REG) = 0;
> +       unfortunately GCC4 notices that this stores (double)0.0 into
> +       env->ft0 and emits that constant into the .rodata, and instructions
> +       to load that zero from there.  But that construct can't be parsed by dyngen.
> +       We could add -ffast-math for compiling op.c, that would just make it generate
> +       two stores of zeros into both words of ft0.  But -ffast-math may have other
> +       side-effects regarding the emulation.  We could use __builtin_memset,
> +       which perhaps would be the sanest.  That relies on -O2 and our other options
> +       to inline that memset, which currently it does, but who knows for how long.
> +       So, we simply do that by hand, and a barely typesafe way :-/  */
> +    union baeh { double d; unsigned int i[2];};
> +    union baeh *p = (union baeh*)&(glue(FT, REG));
> +    p->i[0] = 0;
> +    p->i[1] = 0;
> +#else
>      glue(FT, REG) = 0;
> +#endif
>      RETURN();
>  }
>  
> 
> 

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Blue Swirl]

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

On 8/29/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 29 Aug 2007, Michael Matz wrote:
>
> > On Wed, 29 Aug 2007, Johannes Schindelin wrote:
> >
> > > > Thanks for your effor Michael! Now, I only hope, one of the patches
> > > > that makes qemu gcc4 compliant are soon merged.
> > >
> > > Well, to throw a spanner in the works: this patch is the 4th patch along
> > > the lines that I came about.  None of them (AFAICT) was tested well
> > > enough to be included in CVS.  Indeed, the biggest problem seems to be
> > > to make a patch that not only works on the machine of the poster, but on
> > > other machines, too.
> >
> > Please?  qemu with that patch builds on four architectures, and tests
> > fine on two of them (including cross targets) and only because I haven't
> > run it on the other two architectures yet.
>
> Hey, I am not criticising you!  Instead, I am thankful enough that I went
> so far as to expose it with git.
>
> > It might or might not need more patches than just mine (as I started
> > from our package), but in that case they are independend of making qemu
> > work with gcc 4, which is the only thing my patch is concerned about.
>
> I already reported the non-compiling state of sparc-linux-user...  Any
> idea what I could do about it?

With the attached patch I can run Sparc32 and Sparc64 emulators on x86_64 host.

The performance feels slightly worse. Maybe the patch should be
conditional on GCC >= 4?

I think that the decision of using host registers vs. env fields
should be done in one file at top level.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sparc-tadd.diff --]
[-- Type: text/x-diff; name="sparc-tadd.diff", Size: 469 bytes --]

Index: qemu/target-sparc/op.c
===================================================================
--- qemu.orig/target-sparc/op.c	2007-08-29 17:57:21.000000000 +0000
+++ qemu/target-sparc/op.c	2007-08-29 17:58:00.000000000 +0000
@@ -520,8 +520,11 @@
 {
     target_ulong src1;
 
-    if ((T0 & 0x03) || (T1 & 0x03))
+    if ((T0 & 0x03) || (T1 & 0x03)) {
         raise_exception(TT_TOVF);
+        FORCE_RET();
+        return;
+    }
 
     src1 = T0;
     T0 += T1;

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Carlo Marcelo Arenas Belon]

<SNIP>
On Wed, Aug 29, 2007 at 03:30:45PM +0200, Michael Matz wrote:
> I'm only a compiler developer hitting qemu hard enough until it works with 
> gcc4 :-)

slightly offtopic, but in the last GCC summit 2007 there was a presentation
with an interesting propossal which makes GCC specifically generate code
chunks that would be reused in a different context like it is done with dyngen
for qemu as shown by :

  http://www.gccsummit.org/2007/view_abstract.php?content_key=30

with a description (but sadly no code) in the proceedings (pages 117 to 130)
available from :

  http://ols2006.108.redhat.com/2007/GCC-Reprints/GCC2007-Proceedings.pdf

Carlo

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Michael Matz]

Hi,

On Wed, 29 Aug 2007, Michael Matz wrote:

> > >        I solved that by placing one of the T[012] operands into memory
> > >        for HOST_I386, thereby freeing one reg.  Here's some justification
> > >        of why that doesn't really cost performance: with three free regs
> > >        GCC is already spilling like mad in the snippets, we just trade one
> > >        of those memory accesses (to stack) with one other mem access to
> > >        the cpu_state structure, which will be in cache.
> > 
> > Do you have any evidence to support this claim?
> 
> Not really, only an apple and orange comparison.  A 10000 iteration 
> tests/sha1 run in the same Linux image, with -no-kqemu, on host and target 
> i386:  time ./sha1
> 
> with qemu-0.8.2 (compiled by gcc 3.3-hammer): 7.92 seconds
> with qemu-0.9.0-cvs (gcc4.1 compiled, with the patch): 8.15 seconds
> 
> I'll try to get a better comparison.

So, I've now compared our 0.9.0 package, once without patch compiled by 
3.3-hammer, and once with patch and compiled by gcc 4.2:

gcc33 compiled: 7.81 seconds (i.e. a bit faster than 0.8.2 was)
gcc42 compiled: 8.07 seconds

I.e. 3% slower.


Ciao,
Michael.

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Thiemo Seufer]

Michael Matz wrote:
> Hi,
> 
> [please keep me CCed, I'm not on this list]
> 
> the below patch let's qemu be compiled by GCC 4.2 (probably also 4.1 and 
> others) for most hosts (i386,x86_64,ia64,ppc).  s390 as host is missing, 
> and needs a compiler change to emit the literal store inline again, as the 
> literal pool at the end fundamentally breaks the assumption that qemu can 
> paste together the code snippets by patching out the return.  I have no 
> HOST_{ARM,MIPS*,ALPHA,SPARC*,M68K} machines to compile for that.
> 
> It specifically changes these things:
> 
> * ppc: adds -fno-section-anchors to OP_CFLAGS, as dyngen isn't prepared
>        to deal with the relocs resulting from using section anchors

Maybe this should be handled more generally then, not ppc specific, like
other "offending" compiler options: check if the compiler knows the
option, if yes, disable the feature.

> * ppc: on target-alpha op_reset_FT GCC4 uses a floating point constant 0.0
>        to reset the ft regs, which in turn is loaded from the data 
>        section.  The reloc for that is unhandled.  Using -ffast-math would 
>        work around this, but I chose to be conservative and change only
>        the op.c snippet in question.  See the comment there.
> * i386: well, most of you will know that GCC4 doesn't compile qemu because 
>        of reload.  The inherent problem is, that qemu uses 64bit
>        entities in some places (sometimes structs), which GCC (4.x) 
>        manages to place in registers, i.e. needs 2 hardregs.  But it 
>        sometimes just so happens that an instruction needing such DImode
>        reg also has a memory operand with an indexed address (reg plus 
>        reg), hence two hardregs more.  But qemu by default leaves just 
>        three free registers for compiling op.c --> boom.  This is somewhat 
>        hard to work around in GCC (trust me :) ).
> 
>        I solved that by placing one of the T[012] operands into memory
>        for HOST_I386, thereby freeing one reg.  Here's some justification 
>        of why that doesn't really cost performance: with three free regs
>        GCC is already spilling like mad in the snippets, we just trade one
>        of those memory accesses (to stack) with one other mem access to 
>        the cpu_state structure, which will be in cache.

Could you back up this assumption with some numbers? :-)
If there is a significant difference I recommend to make that workaround
conditional on GCC4 as well as HOST_I386.

[snip]
> diff -urp qemu-0.9.0.cvs.orig/target-arm/cpu.h qemu-0.9.0.cvs/target-arm/cpu.h
> --- qemu-0.9.0.cvs.orig/target-arm/cpu.h	2007-06-24 14:09:48.000000000 +0200
> +++ qemu-0.9.0.cvs/target-arm/cpu.h	2007-08-21 21:38:36.000000000 +0200
> @@ -52,6 +52,9 @@ typedef uint32_t ARMReadCPFunc(void *opa
>   */
>  
>  typedef struct CPUARMState {
> +#if defined(HOST_I386)
> +    uint32_t t1;
> +#endif
>      /* Regs for current mode.  */
>      uint32_t regs[16];
>      /* Frequently accessed CPSR bits are stored separately for efficiently.
> diff -urp qemu-0.9.0.cvs.orig/target-arm/exec.h qemu-0.9.0.cvs/target-arm/exec.h
> --- qemu-0.9.0.cvs.orig/target-arm/exec.h	2007-06-03 19:44:36.000000000 +0200
> +++ qemu-0.9.0.cvs/target-arm/exec.h	2007-08-21 21:48:48.000000000 +0200
> @@ -23,7 +23,12 @@
>  register struct CPUARMState *env asm(AREG0);
>  register uint32_t T0 asm(AREG1);
>  register uint32_t T1 asm(AREG2);
> +#ifndef HOST_I386
>  register uint32_t T2 asm(AREG3);
> +#else
> +#define T2 (env->t1)
> +#endif

T2/t1 mismatch, it seems. Likewise for mips and ppc.


Thiemo

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Michael Matz]

Hi,

On Thu, 30 Aug 2007, Thiemo Seufer wrote:

> > * ppc: adds -fno-section-anchors to OP_CFLAGS, as dyngen isn't prepared
> >        to deal with the relocs resulting from using section anchors
> 
> Maybe this should be handled more generally then, not ppc specific, like
> other "offending" compiler options: check if the compiler knows the
> option, if yes, disable the feature.

Yeah, like is done for the other additions to OP_CFLAGS, which are guarded 
by $(call cc-option, ...).

> >        I solved that by placing one of the T[012] operands into memory
> >        for HOST_I386, thereby freeing one reg.  Here's some justification 
> >        of why that doesn't really cost performance: with three free regs
> >        GCC is already spilling like mad in the snippets, we just trade one
> >        of those memory accesses (to stack) with one other mem access to 
> >        the cpu_state structure, which will be in cache.
> 
> Could you back up this assumption with some numbers? :-)

I did that downthread.  To me the slowdown is not significant enough, 
although it exists.

> > --- qemu-0.9.0.cvs.orig/target-arm/cpu.h	2007-06-24 14:09:48.000000000 +0200
> > +++ qemu-0.9.0.cvs/target-arm/cpu.h	2007-08-21 21:38:36.000000000 +0200
> > @@ -52,6 +52,9 @@ typedef uint32_t ARMReadCPFunc(void *opa
> >   */
> >  
> >  typedef struct CPUARMState {
> > +#if defined(HOST_I386)
> > +    uint32_t t1;
> > +#endif
> >      /* Regs for current mode.  */
> >      uint32_t regs[16];
> >      /* Frequently accessed CPSR bits are stored separately for efficiently.
> > diff -urp qemu-0.9.0.cvs.orig/target-arm/exec.h qemu-0.9.0.cvs/target-arm/exec.h
> > --- qemu-0.9.0.cvs.orig/target-arm/exec.h	2007-06-03 19:44:36.000000000 +0200
> > +++ qemu-0.9.0.cvs/target-arm/exec.h	2007-08-21 21:48:48.000000000 +0200
> > @@ -23,7 +23,12 @@
> >  register struct CPUARMState *env asm(AREG0);
> >  register uint32_t T0 asm(AREG1);
> >  register uint32_t T1 asm(AREG2);
> > +#ifndef HOST_I386
> >  register uint32_t T2 asm(AREG3);
> > +#else
> > +#define T2 (env->t1)
> > +#endif
> 
> T2/t1 mismatch, it seems. Likewise for mips and ppc.

Yes, well, I could have named the env member perhaps "temp" :-)  I can 
change it, though.


Ciao,
Michael.

Re: [Qemu-devel] [patch] make qemu work with GCC 4

[Thiemo Seufer]

Michael Matz wrote:
> Hi,
> 
> On Thu, 30 Aug 2007, Thiemo Seufer wrote:
> 
> > > * ppc: adds -fno-section-anchors to OP_CFLAGS, as dyngen isn't prepared
> > >        to deal with the relocs resulting from using section anchors
> > 
> > Maybe this should be handled more generally then, not ppc specific, like
> > other "offending" compiler options: check if the compiler knows the
> > option, if yes, disable the feature.
> 
> Yeah, like is done for the other additions to OP_CFLAGS, which are guarded 
> by $(call cc-option, ...).
> 
> > >        I solved that by placing one of the T[012] operands into memory
> > >        for HOST_I386, thereby freeing one reg.  Here's some justification 
> > >        of why that doesn't really cost performance: with three free regs
> > >        GCC is already spilling like mad in the snippets, we just trade one
> > >        of those memory accesses (to stack) with one other mem access to 
> > >        the cpu_state structure, which will be in cache.
> > 
> > Could you back up this assumption with some numbers? :-)
> 
> I did that downthread.  To me the slowdown is not significant enough, 
> although it exists.

I would like to have it conditional on GCC4.

> > > --- qemu-0.9.0.cvs.orig/target-arm/cpu.h	2007-06-24 14:09:48.000000000 +0200
> > > +++ qemu-0.9.0.cvs/target-arm/cpu.h	2007-08-21 21:38:36.000000000 +0200
> > > @@ -52,6 +52,9 @@ typedef uint32_t ARMReadCPFunc(void *opa
> > >   */
> > >  
> > >  typedef struct CPUARMState {
> > > +#if defined(HOST_I386)
> > > +    uint32_t t1;
> > > +#endif
> > >      /* Regs for current mode.  */
> > >      uint32_t regs[16];
> > >      /* Frequently accessed CPSR bits are stored separately for efficiently.
> > > diff -urp qemu-0.9.0.cvs.orig/target-arm/exec.h qemu-0.9.0.cvs/target-arm/exec.h
> > > --- qemu-0.9.0.cvs.orig/target-arm/exec.h	2007-06-03 19:44:36.000000000 +0200
> > > +++ qemu-0.9.0.cvs/target-arm/exec.h	2007-08-21 21:48:48.000000000 +0200
> > > @@ -23,7 +23,12 @@
> > >  register struct CPUARMState *env asm(AREG0);
> > >  register uint32_t T0 asm(AREG1);
> > >  register uint32_t T1 asm(AREG2);
> > > +#ifndef HOST_I386
> > >  register uint32_t T2 asm(AREG3);
> > > +#else
> > > +#define T2 (env->t1)
> > > +#endif
> > 
> > T2/t1 mismatch, it seems. Likewise for mips and ppc.
> 
> Yes, well, I could have named the env member perhaps "temp" :-)  I can 
> change it, though.

I did expect T2 to map to env->t2, like it is done for 64bit-emu on
32bit-host. It keeps things a bit more comprehensible. :-)


Thiemo