Re: Building qemu on UltraSparc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Building qemu on UltraSparc

Juergen Keil


> 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           [hidden email]
Tools GmbH +49 (228) 9858011

_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

qemu-solaris-freebsd-netbsd-patch.gz (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building qemu on UltraSparc

Nardmann, Heiko
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.
>
> --
> Juergen Keil           [hidden email]
> Tools GmbH +49 (228) 9858011
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).
patching file bswap.h
patching file configure
Hunk #6 FAILED at 359.
Hunk #7 succeeded at 442 (offset -1 lines).
Hunk #9 succeeded at 502 (offset -1 lines).
Hunk #11 succeeded at 598 (offset -1 lines).
Hunk #13 succeeded at 674 (offset -1 lines).
Hunk #15 succeeded at 780 (offset -1 lines).
1 out of 15 hunks FAILED -- saving rejects to file configure.rej
patching file cpu-exec.c
patching file dyngen-exec.h
patching file dyngen.c
patching file osdep.h
patching file vl.c
Hunk #2 succeeded at 520 (offset -3 lines).
Hunk #4 succeeded at 1631 (offset -3 lines).
patching file vl.h
patching file audio/mixeng.c
patching file fpu/softfloat-native.c
patching file fpu/softfloat-native.h
patching file fpu/softfloat.h
patching file hw/ide.c
Hunk #1 succeeded at 358 (offset -1 lines).
Hunk #3 succeeded at 460 (offset -1 lines).
Hunk #4 succeeded at 894 (offset -24 lines).
Hunk #5 succeeded at 951 (offset -1 lines).
Hunk #6 succeeded at 2204 (offset -26 lines).
Hunk #7 succeeded at 2252 (offset -1 lines).
patching file linux-user/main.c
patching file linux-user/syscall.c
patching file slirp/mbuf.c
patching file slirp/slirp.c
patching file slirp/slirp.h
patching file slirp/socket.c
patching file target-arm/cpu.h
patching file target-i386/cpu.h
patching file target-ppc/cpu.h
patching file target-ppc/helper.c
patching file target-ppc/op_helper.c
patching file target-sparc/cpu.h

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 0x34c216 does not fit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ld: fatal: relocation error: R_SPARC_WDISP22: file libqemu.a(op.o): symbol
__op_gen_label1: value 0x34a0db 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?

I have done this on Solaris 9 on a Sun Fire v250 with gcc-3.4.2 and native
ld/as.

--
Heiko Nardmann (Dipl.-Ing. Technische Informatik)
secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de),
Weidenauer Str. 223-225, D-57076 Siegen
Tel. : +49 271 48950-13, Fax  : +49 271 48950-50

_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building qemu on UltraSparc

Juergen Keil
In reply to this post by Juergen Keil

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__



_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Building qemu on UltraSparc

Nardmann, Heiko
On Dienstag 24 Mai 2005 14:20, Juergen Keil wrote:
[snip]

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

Although I do not fully understand your explanation ... it works now with your
patch.

Thanks!

Does this stuff go into CVS?

--
Heiko Nardmann (Dipl.-Ing. Technische Informatik)
secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de),
Weidenauer Str. 223-225, D-57076 Siegen
Tel. : +49 271 48950-13, Fax  : +49 271 48950-50

_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

attachment0 (196 bytes) Download Attachment