From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cs7mK-00044l-Sn for qemu-devel@nongnu.org; Fri, 21 Jan 2005 18:01:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cs7mD-000411-Af for qemu-devel@nongnu.org; Fri, 21 Jan 2005 18:01:13 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cs7mC-0003xR-UH for qemu-devel@nongnu.org; Fri, 21 Jan 2005 18:01:12 -0500 Received: from [80.91.229.2] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cs7QY-0007Zm-2I for qemu-devel@nongnu.org; Fri, 21 Jan 2005 17:38:50 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Cs7QX-0007M8-00 for ; Fri, 21 Jan 2005 23:38:49 +0100 Received: from amarseille-206-1-11-50.w81-49.abo.wanadoo.fr ([81.49.159.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Jan 2005 23:38:49 +0100 Received: from daimon55 by amarseille-206-1-11-50.w81-49.abo.wanadoo.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Jan 2005 23:38:49 +0100 From: Ronald Date: Fri, 21 Jan 2005 23:38:42 +0100 Message-ID: References: <1f1698a605011520285bc01970@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Sender: news Subject: [Qemu-devel] Re: MacOSX CVS build broken Reply-To: daimon55@free.fr, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Le Sat, 15 Jan 2005 23:28:31 -0500, Tim Douglas a écrit : > On Fri, 14 Jan 2005 21:44:01 -0800, John Tangney > wrote: >> I am still getting the same thing a week later after a fresh cvs update. >> Any hints? > > As am I. Check out this interesting log: > > gcc -Wall -O2 -g -fno-strict-aliasing -D__powerpc__ -fno-reorder-blocks > -fno-optimize-sibling-calls -mdynamic-no-pic -I. > -I/Users/timdoug/Desktop/qemu/target-i386 -I/Users/timdoug/Desktop/qemu > -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE > -I/Users/timdoug/Desktop/qemu/slirp -c -o op.o > /Users/timdoug/Desktop/qemu/target-i386/op.c In file included from > /Users/timdoug/Desktop/qemu/target-i386/exec.h:21, > from /Users/timdoug/Desktop/qemu/target-i386/op.c:22: > /Users/timdoug/Desktop/qemu/dyngen-exec.h:38: warning: redefinition of > `int8_t' /usr/include/ppc/types.h:69: warning: `int8_t' previously > declared here /Users/timdoug/Desktop/qemu/dyngen-exec.h:39: warning: > redefinition of `int16_t' /usr/include/ppc/types.h:71: warning: `int16_t' > previously declared here /Users/timdoug/Desktop/qemu/dyngen-exec.h:40: > warning: redefinition of `int32_t' /usr/include/ppc/types.h:73: warning: > `int32_t' previously declared here > /Users/timdoug/Desktop/qemu/dyngen-exec.h:44: warning: redefinition of > `int64_t' /usr/include/ppc/types.h:75: warning: `int64_t' previously > declared here ../dyngen -o op.h op.o > dyngen: blr expected at the end of op_pmaddwd_mmx make[1]: *** [op.h] > Error 1 > make: *** [all] Error 1 [...] > The first invocation of gcc here makes op.o at 536k. dyngen then fails, > but still makes op.h. > The second run of dyngen fails too, but again it > outputs opc.h. And then translate-all.c fails to build because something > is broken in dyngen_code which is in op.h. So something must indeed be > wrong with dyngen or op.c or something else. Here, though, qemu's internal > workings bypass my knowledge, so I've sent this to qemu-devel too to see > what they can figure out. > If I objdump -D op.o, the asm code for op_pmaddwd_mmx is like this 0000d984 : d984: 3d 20 00 00 lis r9,0 d988: 3d 60 00 00 lis r11,0 d98c: 39 29 00 00 addi r9,r9,0 d990: 39 6b 00 00 addi r11,r11,0 d994: 7d 1b 4a 14 add r8,r27,r9 d998: 7c 9b 5a 14 add r4,r27,r11 d99c: 38 a0 00 00 li r5,0 d9a0: 38 e0 00 04 li r7,4 d9a4: 38 c0 00 06 li r6,6 d9a8: 7d 26 22 ae lhax r9,r6,r4 d9ac: 38 a5 00 01 addi r5,r5,1 d9b0: 7d 46 42 ae lhax r10,r6,r8 d9b4: 2c 05 00 01 cmpwi r5,1 d9b8: 7c 07 22 ae lhax r0,r7,r4 d9bc: 38 c6 ff fc addi r6,r6,-4 d9c0: 7d 67 42 ae lhax r11,r7,r8 d9c4: 7d 29 51 d6 mullw r9,r9,r10 d9c8: 7c 00 59 d6 mullw r0,r0,r11 d9cc: 7d 29 02 14 add r9,r9,r0 d9d0: 7d 27 41 2e stwx r9,r7,r8 d9d4: 38 e7 ff fc addi r7,r7,-4 d9d8: 4d 81 00 20 bgtlr d9dc: 4b ff ff cc b d9a8 this really don't end with blr, but if I have understood correctly what I have found about bgtlr, it should do what blr do with some condition on r0. May be dyngen should verify on 4bffffcc too and not only 4e800020. --- dyngen.c 2005-01-21 23:33:10.576942764 +0100 +++ dyngen.c.new 2005-01-21 23:34:38.326370710 +0100 @@ -1342,7 +1342,10 @@ if (p == p_start) error("empty code for %s", name); if (get32((uint32_t *)p) != 0x4e800020) - error("blr expected at the end of %s", name); + { + if (get32((uint32_t *)p) != 0x4bffffcc) + error("blr or b expected at the end of %s", name); + } copy_size = p - p_start; } #elif defined(HOST_S390) Not sure if all that is correct. > Cheers, > -Tim