[Qemu-devel] Re: MacOSX CVS build broken

[Qemu-devel] Re: MacOSX CVS build broken

[Tim Douglas]

On Fri, 14 Jan 2005 21:44:01 -0800, John Tangney <johnt@jdtangney.com> 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
DualG5:~/Desktop/qemu timdoug$ make
for d in i386-softmmu; do \
make -C $d all || exit 1 ; \
        done
../dyngen -c -o opc.h op.o
dyngen: blr expected at the end of op_pmaddwd_mmx
make[1]: *** [opc.h] Error 1
make: *** [all] Error 1
DualG5:~/Desktop/qemu timdoug$ make
for d in i386-softmmu; do \
make -C $d all || exit 1 ; \
        done
gcc -Wall -O2 -g -fno-strict-aliasing -D__powerpc__ -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
translate-all.o /Users/timdoug/Desktop/qemu/translate-all.c
/Users/timdoug/Desktop/qemu/translate-all.c: In function `dyngen_code':
/Users/timdoug/Desktop/qemu/translate-all.c:290: error: parse error at
end of input
/Users/timdoug/Desktop/qemu/translate-all.c:56: warning: unused
variable `code_copy_enabled'
make[1]: *** [translate-all.o] Error 1
make: *** [all] Error 1
DualG5:~/Desktop/qemu timdoug$

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.

Cheers,
-Tim

Re: [Qemu-devel] Re: MacOSX CVS build broken

[Phil Krylov]

On Sat, 15 Jan 2005 23:28:31 -0500, Tim Douglas <timdoug@gmail.com> wrote:

> 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.

dyngen should remove output file on error, but it doesn't (possibly
for the purpose of debugging), and the next make invocation doesn't
try to rebuild the corrupt .h file.

-- Ph.

[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 <johnt@jdtangney.com>
> 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

Re: [Qemu-devel] Re: MacOSX CVS build broken

[Paul Brook]

>     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.

No, this is not correct.

The reason qemu expects the code sequence to end with blr is because it 
assumes the routine only has a single return statement at the end of the 
function. It then removes that return instructions to chain multiple ops 
together into a single block.

You'll notice that the preceding instruction is bgtlr, so simply accepting the 
"b" would break this assumtion.

The correct solution is to add FORCE_RET() to the end of the end of op_pmaddwd 
in ops_sse.h.

The same probably applies to many of the other routines in that file.

Paul

Re: [Qemu-devel] Re: MacOSX CVS build broken

[Johannes Schindelin]

Hi,

On Fri, 21 Jan 2005, Ronald wrote:

> 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.

The problem: if bgtlr doesn't return, then "b d9a8" is executed, i.e. a
jump to d9a8. However, dyngen wants to strip away the "blr" in order to
chain op_* functions together (and so avoid the overhead of calling them
the normal way). This is not possible, thus your fix ain't one, sorry.

If my explanation is not coherent, please read my qemu-porting.html. It
should become clearer then.

Ciao,
Dscho

Re: [Qemu-devel] Re: MacOSX CVS build broken

[Daniel Egger]

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

On 21.01.2005, at 23:38, Ronald wrote:

>     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.

4e800020 is blr while bgtlr is 4d810020 so if you want to match on
bgtlr as well, the condition to check for would be more something like:

if ((get32((uint32_t *)p) != 0x4e800020) || (get32((uint32_t *)p) != 
0x4d810020))

I would have to check the G4 PEM but there are probably a few more
rarely generated variants which should be matched as well; also
probably there's an elegant bitmask which can be used for testing
this condition....

Servus,
       Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 478 bytes --]

Re: [Qemu-devel] Re: MacOSX CVS build broken

[Fabrice Bellard]

Hi,

The PowerPC build should work now, at least using Linux as host OS.

Fabrice.