qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] Building qemu on UltraSparc
@ 2005-05-21 17:32 Jérôme Warnier
  2005-05-21 23:26 ` Herbert Poetzl
  0 siblings, 1 reply; 8+ messages in thread
From: Jérôme Warnier @ 2005-05-21 17:32 UTC (permalink / raw)
  To: List qemu-devel

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

I'm trying to build qEmu v0.7.0 on Debian Sarge on a Sparc64 machine,
and it fails with strange errors.
Does anybody here have any idea to help me achieve it?

I attach the log of the build to this mail.

Thanks

[-- Attachment #2: qemu_0.7.0-0bxlug0_sparc.build.gz --]
[-- Type: application/x-gzip, Size: 3364 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Building qemu on UltraSparc
@ 2005-05-23  8:38 Juergen Keil
  2005-05-24 10:58 ` Nardmann, Heiko
  0 siblings, 1 reply; 8+ messages in thread
From: Juergen Keil @ 2005-05-23  8:38 UTC (permalink / raw)
  To: qemu-devel

[-- Attachment #1: Type: TEXT/plain, Size: 7591 bytes --]



> Le dimanche 22 mai 2005 à 01:26 +0200, Herbert Poetzl a écrit :
> > On Sat, May 21, 2005 at 07:32:11PM +0200, Jérôme Warnier wrote:
> > > I'm trying to build qEmu v0.7.0 on Debian Sarge on a Sparc64 machine,
> > > and it fails with strange errors.
> > > Does anybody here have any idea to help me achieve it?
> > 
> > well, looks like you hit 32 vs 64 bit issues here, don't know
> > the details about the sparc/64 support but I'd try to build
> > as sparc32 first and see how far that gets ...
> I tried that (starting with utility sparc32), and it even fails faster.
> See the log attached.
> 
> > HTH,
> > Herbert
> 
> > > I attach the log of the build to this mail.
> > > 
> > > Thanks
> 
> Thanks for your help.
> 
> [..]


SPARC Host support is quite broken at this time, it seems.


> In file included from 
/home/jwarnier/debian/qemu-0.7.0/target-i386/op.c:724:/home/jwarnier/debian/qemu-0.7.0/targe
t-i386/ops_template.h: In function `op_jb_subb':
> /home/jwarnier/debian/qemu-0.7.0/target-i386/ops_template.h:278: warning: implicit 
declaration of function `GOTO_LABEL_PARAM'


Yep, the macro GOTO_LABEL_PARAM is not defined for the sparc platform.

This needs to be fixed in dyngen-exec.h, with something like this:

Index: dyngen-exec.h
===================================================================
RCS file: /cvsroot/qemu/qemu/dyngen-exec.h,v
retrieving revision 1.25
diff -u -B -b -u -6 -r1.25 dyngen-exec.h
--- dyngen-exec.h       24 Apr 2005 18:01:56 -0000      1.25
+++ dyngen-exec.h       23 May 2005 08:04:45 -0000
@@ -225,14 +246,14 @@
 #ifdef __ia64__
 #define EXIT_TB() asm volatile ("br.ret.sptk.many b0;;")
 #define GOTO_LABEL_PARAM(n) asm volatile ("br.sptk.many " \
                                          ASM_NAME(__op_gen_label) #n)
 #endif
 #ifdef __sparc__
-#define EXIT_TB() asm volatile ("jmpl %i0 + 8, %g0\n" \
-                                "nop")
+#define EXIT_TB() asm volatile ("jmpl %i0 + 8, %g0; nop")
+#define        GOTO_LABEL_PARAM(n) asm volatile ("ba " ASM_NAME(__op_gen_label) #n ";nop")
 #endif
 #ifdef __arm__
 #define EXIT_TB() asm volatile ("b exec_loop")
 #define GOTO_LABEL_PARAM(n) asm volatile ("b " ASM_NAME(__op_gen_label) #n)
 #endif
 #ifdef __mc68000


The new "ba" instruction also requires a new type of relocation support for
R_SPARC_WDISP22 relocations in dyngen:

Index: dyngen.c
===================================================================
RCS file: /cvsroot/qemu/qemu/dyngen.c,v
retrieving revision 1.40
diff -u -B -b -u -6 -r1.40 dyngen.c
--- dyngen.c    27 Apr 2005 19:55:58 -0000      1.40
+++ dyngen.c    23 May 2005 08:04:45 -0000
@@ -2142,12 +2142,24 @@
                                    "    & 0x3fffffff);\n",
                                    rel->r_offset - start_offset,
                                    rel->r_offset - start_offset,
                                    name, addend,
                                    rel->r_offset - start_offset);
                            break;
+                       case R_SPARC_WDISP22:
+                           fprintf(outfile,
+                                   "    *(uint32_t *)(gen_code_ptr + %d) = "
+                                   "((*(uint32_t *)(gen_code_ptr + %d)) "
+                                   " & ~0x3fffff) "
+                                   " | ((((%s + %d) - (long)(gen_code_ptr + %d))>>2) "
+                                   "    & 0x3fffff);\n",
+                                   rel->r_offset - start_offset,
+                                   rel->r_offset - start_offset,
+                                   name, addend,
+                                   rel->r_offset - start_offset);
+                           break;
                         default:
                             error("unsupported sparc relocation (%d)", type);
                         }
                     }
                 }
             }


sparc64 probably needs a similar change to support WDISP22 relocations.



> ../dyngen -o op.h op.o
> dyngen: Found bogus save at the start of op_pavgb_mmx


That's another issue with sparc host support. x86 MMX instruction
support was added to qemu some time ago, and the compiler needs a *lot*
of register variables for the MMX opcode code templates.  Problem is
that on sparc a lot of cpu registers are already in use as "global
register" variables: most sparc global registers g1-g3, g6 and all local
registers l0-l7.  So the compiler starts to generate code that uses
frame pointer relative temporary variables in memory, because it's
running out of free cpu registers.  The use of temporary variables in
memory is incompatible with the way qemu's dyngen code generator works
on sparc.  That's basically what dyngen seems to be complaining about.



I've fixed this for now for Solaris SPARC host support, by reducing the
number of global cpu registers to just the global registers (g2-g6) -
freeing the local registers l0-l7.  With that change op_pavgb_mmx
doesn't need temporary variables in the local stack frame any more.

Index: dyngen-exec.h
===================================================================
RCS file: /cvsroot/qemu/qemu/dyngen-exec.h,v
retrieving revision 1.25
diff -u -B -b -u -6 -r1.25 dyngen-exec.h
--- dyngen-exec.h       24 Apr 2005 18:01:56 -0000      1.25
+++ dyngen-exec.h       23 May 2005 08:04:45 -0000
@@ -106,24 +119,32 @@
 #define AREG0 "s3"
 #define AREG1 "s0"
 #define AREG2 "s1"
 #define AREG3 "s2"
 #endif
 #ifdef __sparc__
+#ifdef _SOLARIS
+#define AREG0 "g2"
+#define AREG1 "g3"
+#define AREG2 "g4"
+#define AREG3 "g5"
+#define AREG4 "g6"
+#else
 #define AREG0 "g6"
 #define AREG1 "g1"
 #define AREG2 "g2"
 #define AREG3 "g3"
 #define AREG4 "l0"
 #define AREG5 "l1"
 #define AREG6 "l2"
 #define AREG7 "l3"
 #define AREG8 "l4"
 #define AREG9 "l5"
 #define AREG10 "l6"
 #define AREG11 "l7"
+#endif
 #define USE_FP_CONVERT
 #endif
 #ifdef __s390__
 #define AREG0 "r10"
 #define AREG1 "r7"
 #define AREG2 "r8"
Index: Makefile.target
===================================================================
RCS file: /cvsroot/qemu/qemu/Makefile.target,v
retrieving revision 1.69
diff -u -B -b -u -6 -r1.69 Makefile.target
--- Makefile.target     28 Apr 2005 21:15:08 -0000      1.69
+++ Makefile.target     23 May 2005 08:04:44 -0000
@@ -157,19 +157,25 @@
 ifeq ($(ARCH),s390)
 OP_CFLAGS=$(CFLAGS)
 LDFLAGS+=-Wl,-T,$(SRC_PATH)/s390.ld
 endif

 ifeq ($(ARCH),sparc)
+ifeq ($(CONFIG_SOLARIS),yes)
+CFLAGS+=-m32 -ffixed-g2 -ffixed-g3
+LDFLAGS+=-m32
+OP_CFLAGS=$(CFLAGS) -fno-delayed-branch -fno-omit-frame-pointer -ffixed-i0
+else
 CFLAGS+=-m32 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6
 LDFLAGS+=-m32
 OP_CFLAGS=$(CFLAGS) -fno-delayed-branch -ffixed-i0
 HELPER_CFLAGS=$(CFLAGS) -ffixed-i0 -mflat
 # -static is used to avoid g1/g3 usage by the dynamic linker
 LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc.ld -static
 endif
+endif

 ifeq ($(ARCH),sparc64)
 CFLAGS+=-m64 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6
 LDFLAGS+=-m64
 OP_CFLAGS=$(CFLAGS) -fno-delayed-branch -ffixed-i0
 endif


All of the above changes are part of bigger Solaris x86 / Solaris SPARC
/ FreeBSD / NetBSD patch that I'll attach below.


This patch won't immediately fix the issues that you've got on
linux/sparc, but it should give you some ideas where to start fixing
the build issues.

--
Juergen Keil          		jk@tools.de
Tools GmbH			+49 (228) 9858011

[-- Attachment #2: qemu-solaris-freebsd-netbsd-patch.gz --]
[-- Type: APPLICATION/octet-stream, Size: 15427 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Building qemu on UltraSparc
@ 2005-05-24 12:20 Juergen Keil
  2005-05-24 15:14 ` Nardmann, Heiko
  0 siblings, 1 reply; 8+ messages in thread
From: Juergen Keil @ 2005-05-24 12:20 UTC (permalink / raw)
  To: qemu-devel; +Cc: Heiko.Nardmann


Heiko.Nardmann wrote:

> On Montag 23 Mai 2005 10:38, Juergen Keil wrote:
> [snip]
> > All of the above changes are part of bigger Solaris x86 / Solaris SPARC
> > / FreeBSD / NetBSD patch that I'll attach below.
> >
> >
> > This patch won't immediately fix the issues that you've got on
> > linux/sparc, but it should give you some ideas where to start fixing
> > the build issues.
> 
> You probably did your diff against CVS? I have tried it using with clean 0.7.0 
> distribution (gpatch -p0 < ../qemu-solaris-freebsd-netbsd--patch) and got the 
> following:
> 
> patching file Makefile
> patching file Makefile.target
> patching file block.c
> Hunk #1 succeeded at 528 (offset -3 lines).
> ...

Yes, the patch was against current qemu cvs sources.


> This has not been a problem. I have done the following configure call then:
> 
> ./configure --prefix=$HOME/qemu-0.7.0.installed --target-list="i386-softmmu" 
> --cc=gcc-3.4.2 --interp-prefix=$HOME/qemu-0.7.0.installed
> 
> Fine, too. Also compilation works fine. But linking fails with the following 
> error message:
> 
> ld: fatal: relocation error: R_SPARC_WDISP22: file libqemu.a(op.o): symbol 
> __op_gen_label1: value 0x34c21f does not fit
> ...
> ld: fatal: relocation error: R_SPARC_WDISP22: file libqemu.a(op.o): symbol 
> __op_gen_label1: value 0x34a0d3 does not fit
> 
> collect2: ld returned 1 exit status
> 
> Any idea what is happening here?


Part of the problem is my GOTO_LABEL_PARAM macro for sparc, in dyngen-exec.h:

    #define GOTO_LABEL_PARAM(n) asm volatile ("ba " ASM_NAME(__op_gen_label) #n 
";nop")


We have 22 bits in the branch instruction to encode a signed 32-bit word
offset, relative to the current PC. The target address is always a
multiple of 4, so the offset encoded in the branch instruction is an
offset measured in 32-bit words.


The sparc branch instructions cannot jump forward / backward more than
8 mbytes (2^21 * 4 = 8mbyte).


What appears to be happening on your system is that the opcode
templates from the code section for "target-i386/op.c" (these contain
the "ba" branch instruction from the GOTO_LABEL_PARAM macro) jump to an
integer variable that is allocated somewhere in the data or bss section
(the "int __op_gen_label1" variable defined in dyngen.h), and the code
& data section on your system are more than 8 mbytes apart.


Apparently I had luck upto now, because on my solaris 10 sparc box there
have been no such issues with R_SPARC_WDISP22 relocation errors.


> ld: fatal: relocation error: R_SPARC_WDISP22: file libqemu.a(op.o): symbol 
> __op_gen_label1: value 0x34c21f does not fit

  --> 0x34c21f * 4 = 13830268 = 13.8 mbytes


I guess this can be fixed by moving the branch target "__op_gen_label1"
from the data section to the code section.  A "size" on my sparc qemu
binary reports a total code size of ~ 1 mbyte, so that there should be
no issues with R_SPARC_WDISP22 overflows when both the branch instruction
and the branch target are both in the code (.text) section.

A fix would be:

Index: dyngen.h
===================================================================
RCS file: /cvsroot/qemu/qemu/dyngen.h,v
retrieving revision 1.8
diff -u -B -r1.8 dyngen.h
--- dyngen.h    7 Apr 2005 22:20:28 -0000       1.8
+++ dyngen.h    24 May 2005 12:03:11 -0000
@@ -19,7 +19,13 @@
  */

 int __op_param1, __op_param2, __op_param3;
+#ifdef __sparc__
+void __op_gen_label1(){}
+void __op_gen_label2(){}
+void __op_gen_label3(){}
+#else
 int __op_gen_label1, __op_gen_label2, __op_gen_label3;
+#endif
 int __op_jmp0, __op_jmp1, __op_jmp2, __op_jmp3;

 #ifdef __i386__

^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-09-04  1:23 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-21 17:32 [Qemu-devel] Building qemu on UltraSparc Jérôme Warnier
2005-05-21 23:26 ` Herbert Poetzl
2005-05-22  0:13   ` Jérôme Warnier
2005-09-04  1:13     ` Jérôme Warnier
  -- strict thread matches above, loose matches on Subject: below --
2005-05-23  8:38 Juergen Keil
2005-05-24 10:58 ` Nardmann, Heiko
2005-05-24 12:20 Juergen Keil
2005-05-24 15:14 ` Nardmann, Heiko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).