qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jurij Smakov <jurij@wooyd.org>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Some patches for qemu on sparc
Date: Tue, 7 Feb 2006 22:28:15 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.63.0602072227330.14259@bobcat> (raw)

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

Hi,

I'm trying to make qemu build on linux-sparc (Debian port). I've made some 
progress and sent the message included below to Debian qemu maintainers. They 
are probably too busy with other stuff, so I hope I can get some feedback from 
you. Please CC the replies to me since I'm not subscribed to this list.

Thanks,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

---------- Forwarded message ----------
Date: Thu, 26 Jan 2006 22:05:11 -0800 (PST)
From: Jurij Smakov <jurij@wooyd.org>
To: 317145@bugs.debian.org, 317145-submitter@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Some patches for qemu on sparc

found 317145 0.8.0-1
thanks

Hi,

I've started fiddling with qemu 0.8.0-1 on sparc in attempt to make it build. 
That's the issues I've encountered so far:

* Current build failure of qemu on sparc buildd was, in part, the buildd's
     fault. Due to a misconfiguration it was operating in 64-bit mode, which
     should not normally happen. Thanks for Ryan Murray for fixing it in no
     time.

* Nevertheless, even in intended 32-bit mode it still fails to build with
     the messages:

       gcc-3.4 -Wall -O2 -g -fno-strict-aliasing -m32 -ffixed-g1 -ffixed-g2
       -ffixed-g3 -ffixed-g6 -fno-delayed-branch -ffixed-i0 -fno-reorder-blocks
       -fno-optimize-sibling-calls -I.
       -I/home/jurij/tmp/qemu-0.8.0/./target-i386
       -I/home/jurij/tmp/qemu-0.8.0/. -I/home/jurij/tmp/qemu-0.8.0/./linux-user
       -I/home/jurij/tmp/qemu-0.8.0/./linux-user/i386 -D_GNU_SOURCE
       -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
       -I/home/jurij/tmp/qemu-0.8.0/./fpu -DHAS_AUDIO
       -I/home/jurij/tmp/qemu-0.8.0/./slirp -c -o op.o
       /home/jurij/tmp/qemu-0.8.0/./target-i386/op.c
       In file included from /home/jurij/tmp/qemu-0.8.0/./target-i386/op.c:736:
       /home/jurij/tmp/qemu-0.8.0/./target-i386/ops_template.h: In function
       `op_jb_subb':
       /home/jurij/tmp/qemu-0.8.0/./target-i386/ops_template.h:278: warning:
       implicit declaration of function `GOTO_LABEL_PARAM'
       ../dyngen -o op.h op.o
       dyngen: Found bogus save at the start of op_pavgb_xmm
       make[2]: *** [op.h] Error 1
       make[2]: Leaving directory `/home/jurij/tmp/qemu-0.8.0/i386-user'
       make[1]: *** [all] Error 1
       make[1]: Leaving directory `/home/jurij/tmp/qemu-0.8.0'
       make: *** [debian/stamp-makefile-build] Error 2

     After some googling I was able to find fixes for this problem, mentioned
     on the upstream mailing list [0]. For some reason they did not get
     included in the current version.

* After applying the patches mentioned there, it proceeds a bit further,
     to fail again with the messages:

       gcc-3.4 -g -m32 -Wl,-T,/home/jurij/tmp/qemu-0.8.0/./sparc.ld -static -o
       qemu-i386 elfload.o main.o syscall.o mmap.o signal.o path.o osdep.o
       thunk.o vm86.o libqemu.a gdbstub.o   -lm -lrt
       /usr/bin/ld: BFD 2.16.91 20060118 Debian GNU/Linux assertion fail
       ../../bfd/elf.c:3864
       /usr/bin/ld: qemu-i386: Not enough room for program headers (allocated 5,
       need 6)
       /usr/bin/ld: final link failed: Bad value
       collect2: ld returned 1 exit status
       make[2]: *** [qemu-i386] Error 1
       make[2]: Leaving directory `/home/jurij/tmp/qemu-0.8.0/i386-user'
       make[1]: *** [all] Error 1
       make[1]: Leaving directory `/home/jurij/tmp/qemu-0.8.0'
       make: *** [debian/stamp-makefile-build] Error 2

     There appears to be no good solution for that kind of problem around.
     AFAICT, it's not binutils bug, but rather the problem with the linker
     script sparc.ld. It should be fixed somehow, but nobody appears to know
     how, so people were just replacing SIZEOF_HEADERS in the linker script
     with some reasonably big number [1] :-). Replacing it with 0x400 did fix
     the issue.

* That brought me further again, but still no cookie. Now it fails while
     building the arm target:

       gcc-3.4 -Wall -O2 -g -fno-strict-aliasing -m32 -ffixed-g1 -ffixed-g2
       -ffixed-g3 -ffixed-g6 -fno-delayed-branch -ffixed-i0 -fno-reorder-blocks
       -fno-optimize-sibling-calls -I. -I/home/jurij/tmp/qemu-0.8.0/./target-arm
       -I/home/jurij/tmp/qemu-0.8.0/. -I/home/jurij/tmp/qemu-0.8.0/./linux-user
       -I/home/jurij/tmp/qemu-0.8.0/./linux-user/arm -D_GNU_SOURCE
       -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
       -I/home/jurij/tmp/qemu-0.8.0/./fpu -I/home/jurij/tmp/qemu-0.8.0/./slirp
       -c
       -o op.o /home/jurij/tmp/qemu-0.8.0/./target-arm/op.c
       ../dyngen -o op.h op.o
       dyngen: No save at the beginning of op_movl_T0_r0
       make[2]: *** [op.h] Error 1
       make[2]: Leaving directory `/home/jurij/tmp/qemu-0.8.0/arm-user'
       make[1]: *** [all] Error 1
       make[1]: Leaving directory `/home/jurij/tmp/qemu-0.8.0'
       make: *** [debian/stamp-makefile-build] Error 2

     Function op_movl_T0_r0 (and others) in arm-user/op.o indeed does not
     contain a save in the beginning. That's how it looks according to
     objdump -d arm-user/op.o:

       00000000 <op_movl_T0_r0>:
          0:       c2 01 80 00     ld  [ %g6 ], %g1
          4:       81 c3 e0 08     retl
          8:       01 00 00 00     nop

     I have no idea how to fix that one, nor was I able to find anything
     relevant on the net (even though I did not look too hard). If you (or
     upstream) have any ideas regarding this, please let me know.

   Attached patch implements all the changes which got me that far.

[0] http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg00039.html
[1] http://bugs.gentoo.org/show_bug.cgi?id=51078 comment #13

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1930 bytes --]

diff -aur a/dyngen.c b/dyngen.c
--- a/dyngen.c	2005-12-19 14:51:53.000000000 -0800
+++ b/dyngen.c	2006-01-26 21:30:28.109776664 -0800
@@ -1196,7 +1196,7 @@
     } else {
 #ifdef HOST_SPARC
         if (sym_name[0] == '.')
-            snprintf(name, sizeof(name),
+            snprintf(name, name_size,
                      "(long)(&__dot_%s)",
                      sym_name + 1);
         else
@@ -1451,7 +1451,9 @@
         if ((start_insn & ~0x1fff) == 0x9de3a000) {
             p_start += 0x4;
             start_offset += 0x4;
-            if ((int)(start_insn | ~0x1fff) < -128)
+            // if ((int)(start_insn | ~0x1fff) < -128)
+           // Why -128?  op_pavgb_xmm adjusts the stack by -0x110 == -272
+            if ((int)(start_insn | ~0x1fff) < -272)
                 error("Found bogus save at the start of %s", name);
             if (end_insn1 != 0x81c7e008 || end_insn2 != 0x81e80000)
                 error("ret; restore; not found at end of %s", name);
diff -aur a/dyngen-exec.h b/dyngen-exec.h
--- a/dyngen-exec.h	2005-12-19 14:51:53.000000000 -0800
+++ b/dyngen-exec.h	2006-01-26 21:30:18.492238752 -0800
@@ -231,6 +231,8 @@
 #ifdef __sparc__
 #define EXIT_TB() asm volatile ("jmpl %i0 + 8, %g0\n" \
                                 "nop")
+#define        GOTO_LABEL_PARAM(n) asm volatile ( \
+               "set " ASM_NAME(__op_gen_label) #n ", %g1; jmp %g1; nop")
 #endif
 #ifdef __arm__
 #define EXIT_TB() asm volatile ("b exec_loop")
Only in b: dyngen-exec.h.orig
diff -aur a/sparc.ld b/sparc.ld
--- a/sparc.ld	2005-12-19 14:51:53.000000000 -0800
+++ b/sparc.ld	2006-01-26 21:30:45.939066200 -0800
@@ -6,7 +6,7 @@
 SECTIONS
 {
   /* Read-only sections, merged into text segment: */
-  . = 0x60000000 + SIZEOF_HEADERS;
+  . = 0x60000000 + 0x400;
   .interp     : { *(.interp) 	}
   .hash          : { *(.hash)		}
   .dynsym        : { *(.dynsym)		}

                 reply	other threads:[~2006-02-08  6:28 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.63.0602072227330.14259@bobcat \
    --to=jurij@wooyd.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).