[Qemu-devel] Re: MacOSX CVS build broken

[Ronald]

Le Sat, 15 Jan 2005 23:28:31 -0500, Tim Douglas a écrit :

> On Fri, 14 Jan 2005 21:44:01 -0800, John Tangney <address@hidden>
> 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 <op_pmaddwd_mmx>:
    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 <op_pmaddwd_mmx+0x24>

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