[Qemu-devel] Misbehavior of qemu ppc tcg/translation?

[Qemu-devel] Misbehavior of qemu ppc tcg/translation?

[Baojun Wang]

hi, list:

  I hope the following example is self-explained, in the assembler
code, we can use instruction like (instruction-as-data?):

                100000b4:       10 00 12 34     .long 0x10001234

  but the ppc translator set the exception flag and raise a PROGRAM
exception later, however on real machine, if the above instruction is
never ran, then everything should be OK. Thus the ppc translator raise
the exception too early? (I think it should only raise the PROGRAM
exception until tcg really trying to exec the instruction, but not on
translation time)

  Thanks,
Wang Baojun

$ qemu-ppc -L emu-ppc ./hello
hello, world!
invalid/unsupported opcode: 04 - 1a - 08 (10001234) 100000b4 0
Invalid instruction
NIP 100000b8   LR 100000b4 CTR 00000000 XER 00000000
MSR 00006040 HID0 00000000  HF 00006000 idx 0
TB 00000000 00000000
GPR00 0000000000000004 000000004007f588 0000000000000000 000000000000000f
GPR04 00000000100100c4 000000000000000f 0000000000000000 0000000000000000
GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffff
FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPSCR 00000000
Segmentation fault


on a real machine:
$ ./hello
hello, world!
$ powerpc-unknown-linux-gnu-objdump -d hello

hello:     file format elf32-powerpc

Disassembly of section .text:

10000094 <_raw_write>:
10000094:       44 00 00 02     sc
10000098:       4e 80 00 20     blr

1000009c <_start>:
1000009c:       38 00 00 04     li      r0,4
100000a0:       38 60 00 01     li      r3,1
100000a4:       3c 80 10 01     lis     r4,4097
100000a8:       38 84 00 c4     addi    r4,r4,196
100000ac:       38 a0 00 0f     li      r5,15
100000b0:       4b ff ff e5     bl      10000094 <_raw_write>
100000b4:       10 00 12 34     .long 0x10001234
100000b8:       38 00 00 01     li      r0,1
100000bc:       38 60 00 00     li      r3,0
100000c0:       44 00 00 02     sc

[Qemu-devel] Re: Misbehavior of qemu ppc tcg/translation?

[Baojun Wang]

BTW: The source code is dummy:

# hello.S

.data

msg:
        .string "hello, world!\n"
        len = . - msg

.text

        .global _raw_write
_raw_write:
        sc
        blr

        .global _start
_start:
        li 0, 4
        li 3, 1
        lis 4, msg@ha
        addi 4, 4, msg@l
        li 5, len
        bl _raw_write
        .long 0x10001234

        li 0, 1
        li 3, 0
        sc



On Wed, Jul 15, 2009 at 11:33 PM, Baojun Wang<wangbj@gmail.com> wrote:
> hi, list:
>
>  I hope the following example is self-explained, in the assembler
> code, we can use instruction like (instruction-as-data?):
>
>                100000b4:       10 00 12 34     .long 0x10001234
>
>  but the ppc translator set the exception flag and raise a PROGRAM
> exception later, however on real machine, if the above instruction is
> never ran, then everything should be OK. Thus the ppc translator raise
> the exception too early? (I think it should only raise the PROGRAM
> exception until tcg really trying to exec the instruction, but not on
> translation time)
>
>  Thanks,
> Wang Baojun
>
> $ qemu-ppc -L emu-ppc ./hello
> hello, world!
> invalid/unsupported opcode: 04 - 1a - 08 (10001234) 100000b4 0
> Invalid instruction
> NIP 100000b8   LR 100000b4 CTR 00000000 XER 00000000
> MSR 00006040 HID0 00000000  HF 00006000 idx 0
> TB 00000000 00000000
> GPR00 0000000000000004 000000004007f588 0000000000000000 000000000000000f
> GPR04 00000000100100c4 000000000000000f 0000000000000000 0000000000000000
> GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffff
> FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPSCR 00000000
> Segmentation fault
>
>
> on a real machine:
> $ ./hello
> hello, world!
> $ powerpc-unknown-linux-gnu-objdump -d hello
>
> hello:     file format elf32-powerpc
>
> Disassembly of section .text:
>
> 10000094 <_raw_write>:
> 10000094:       44 00 00 02     sc
> 10000098:       4e 80 00 20     blr
>
> 1000009c <_start>:
> 1000009c:       38 00 00 04     li      r0,4
> 100000a0:       38 60 00 01     li      r3,1
> 100000a4:       3c 80 10 01     lis     r4,4097
> 100000a8:       38 84 00 c4     addi    r4,r4,196
> 100000ac:       38 a0 00 0f     li      r5,15
> 100000b0:       4b ff ff e5     bl      10000094 <_raw_write>
> 100000b4:       10 00 12 34     .long 0x10001234
> 100000b8:       38 00 00 01     li      r0,1
> 100000bc:       38 60 00 00     li      r3,0
> 100000c0:       44 00 00 02     sc
>

Re: [Qemu-devel] Misbehavior of qemu ppc tcg/translation?

[Blue Swirl]

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

On 7/15/09, Baojun Wang <wangbj@gmail.com> wrote:
> hi, list:
>
>   I hope the following example is self-explained, in the assembler
>  code, we can use instruction like (instruction-as-data?):
>
>                 100000b4:       10 00 12 34     .long 0x10001234
>
>   but the ppc translator set the exception flag and raise a PROGRAM
>  exception later, however on real machine, if the above instruction is
>  never ran, then everything should be OK. Thus the ppc translator raise
>  the exception too early? (I think it should only raise the PROGRAM
>  exception until tcg really trying to exec the instruction, but not on
>  translation time)

Would the attached patch fix the problem?

[-- Attachment #2: 0001-PPC-stop-code-generation-when-we-reach-a-branch.patch --]
[-- Type: application/x-patch, Size: 1163 bytes --]

Re: [Qemu-devel] Misbehavior of qemu ppc tcg/translation?

[Baojun Wang]

Sorry, I think my example have some problem, because the instruction
after the `bl' would also be executed, I think the reason why on a
real machine (e500v2) doesn't PROGRAM is because of the SPE
instruction:

efdabs 0 0 0 1 0 0 rD rA /// 0 1 0 1 1 1 0 0 1 0 0 EFX efdabs
efdadd 0 0 0 1 0 0 rD rA rB 0 1 0 1 1 1 0 0 0 0 0 EFX efdadd
efdcfs 0 0 0 1 0 0 rD 0 0 0 0 0 rB 0 1 0 1 1 1 0 1 1 1 1 EFX efdcfs
efdcfsf 0 0 0 1 0 0 rD /// rB 0 1 0 1 1 1 1 0 0 1 1 EFX efdcfsf
efdcfsi 0 0 0 1 0 0 rD /// rB 0 1 0 1 1 1 1 0 0 0 1 EFX efdcfsi
efdcfuf 0 0 0 1 0 0 rD /// rB 0 1 0 1 1 1 1 0 0 1 0 EFX efdcfuf
efdcfui 0 0 0 1 0 0 rD /// rB 0 1 0 1 1 1 1 0 0 0 0 EFX efdcfui
efdcmpeq 0 0 0 1 0 0 crfD / / rA rB 0 1 0 1 1 1 0 1 1 1 0 EFX efdcmpeq


opcode(0x10001234) ==> opcode = 4
which will be the above instructions on e500.

I have changed my program, not it looks like:
.data

msg:
        .string "hello, world!\n"
        len = . - msg

.text

        .global _my_cont
_my_cont:
        li 0, 1
        li 3, 0
        sc

        .global _my_write
_my_write:
        stwu 1, -16(1)
        mflr 6
        lwz 4, 0(6)
        lwz 5, 4(6)
        lwz 7, 8(6)
        stw 6, 0(1)
        stw 7, 4(1)
        sc
        lwz 6, 0(1)
        lwz 7, 8(6)
        mtlr 7
        addi 1, 1, 16
        blr

        .global _start
_start:
        li 0, 4
        li 3, 1
        bl _my_write
        .long msg
        .long len
        .long _my_cont

On both qemu & real machine, the code runs fine. I ran into infinite
PROGRAM exception incidentally (NEED further confirm) in ppc-softmmu,
which is more or less simular with the above example because of:

(arch/powerpc/kernel/head_booke.h)
#define EXC_XFER_TEMPLATE(hdlr, trap, msr, copyee, tfer, ret)	\
	li	r10,trap;					\
	stw	r10,_TRAP(r11);					\
	lis	r10,msr@h;					\
	ori	r10,r10,msr@l;					\
	copyee(r10, r9);					\
	bl	tfer;		 				\
	.long	hdlr;						\
	.long	ret

Anyway, Thank you very much!

  Best Regards,
Wang Baojun


On Thu, Jul 16, 2009 at 12:34 AM, Blue Swirl<blauwirbel@gmail.com> wrote:
> On 7/15/09, Baojun Wang <wangbj@gmail.com> wrote:
>> hi, list:
>>
>>   I hope the following example is self-explained, in the assembler
>>  code, we can use instruction like (instruction-as-data?):
>>
>>                 100000b4:       10 00 12 34     .long 0x10001234
>>
>>   but the ppc translator set the exception flag and raise a PROGRAM
>>  exception later, however on real machine, if the above instruction is
>>  never ran, then everything should be OK. Thus the ppc translator raise
>>  the exception too early? (I think it should only raise the PROGRAM
>>  exception until tcg really trying to exec the instruction, but not on
>>  translation time)
>
> Would the attached patch fix the problem?
>