qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1248168] [NEW] MIPS, self-modifying code and uncac


From: Antony Pavlov
Subject: Re: [Qemu-devel] [Bug 1248168] [NEW] MIPS, self-modifying code and uncached memory
Date: Tue, 5 Nov 2013 20:24:23 +0400

On Tue, 05 Nov 2013 12:47:13 -0000
Nikita Kanunnikov <address@hidden> wrote:

Could you please provide some additional information for error reproducing?
(qemu version, necessary binary files, qemu cmdline etc)

Par exemple I have tried to reproduce your error on qemu-1.6.1.

I use qemu-system-mips (so it's big-endian) and the "-M malta -m 256" options.

I have put your code starting at 0xa0000000 (kseg1 first address).

Here is a part of my gdb log:

=> 0xa0000390:   00 00 50 25    move    t2,zero
(gdb) stepi
=> 0xa0000394:   34 0b 00 02    li      t3,0x2
(gdb) stepi
=> 0xa0000398:   01 4b 50 23    subu    t2,t2,t3
(gdb) stepi
=> 0xa000039c:   0b 3c 00 e9    j       0xacf003a4
(gdb)

In fact there is no problem with 0xacf003a4 address. It is normal KSEG1 RAM 
address
on Malta with 256M RAM! May be it contains some rational code.

Could you describe step-by-step what you have done exactly to reproduce the 
error?

> Public bug reported:
> 
> Self-modifying code does not work properly in MIPS in uncached and
> unmapped kseg1 memory region.
> 
> For example, when running this code I get unexpected behavior:
> 
>    0: e3000010        b       0x390
>    4: 00000000        nop
>       ...
>  380: 00701f40        mfc0    ra,c0_epc
>  384: 0400e0bb        swr     zero,4(ra)
>  388: 18000042        eret
>  38c: 00000000        nop
>  390: 25500000        move    t2,zero
>  394: 02000b34        li      t3,0x2
>  398: 23504b01        subu    t2,t2,t3
>  39c: e9003c0b        j       0xcf003a4
>  3a0: 0a004a21        addi    t2,t2,10
>  3a4: ffff0010        b       0x3a4
>  3a8: 00000000        nop
>  3ac: 00000000        nop
> 
>   I expect that swr instruction in line 384 would change `addi        
> t2,t2,1`0 to `nop`
> This should work because no cache is used for this memory region.
> 
> ** Affects: qemu
>      Importance: Undecided
>          Status: New
> 
> -- 
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1248168
> 
> Title:
>   MIPS, self-modifying code and uncached memory
> 
> Status in QEMU:
>   New
> 
> Bug description:
>   Self-modifying code does not work properly in MIPS in uncached and
>   unmapped kseg1 memory region.
> 
>   For example, when running this code I get unexpected behavior:
> 
>      0:       e3000010        b       0x390
>      4:       00000000        nop
>       ...
>    380:       00701f40        mfc0    ra,c0_epc
>    384:       0400e0bb        swr     zero,4(ra)
>    388:       18000042        eret
>    38c:       00000000        nop
>    390:       25500000        move    t2,zero
>    394:       02000b34        li      t3,0x2
>    398:       23504b01        subu    t2,t2,t3
>    39c:       e9003c0b        j       0xcf003a4
>    3a0:       0a004a21        addi    t2,t2,10
>    3a4:       ffff0010        b       0x3a4
>    3a8:       00000000        nop
>    3ac:       00000000        nop
> 
>     I expect that swr instruction in line 384 would change `addi      
> t2,t2,1`0 to `nop`
>   This should work because no cache is used for this memory region.
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1248168/+subscriptions
> 


-- 
-- 
Best regards,
  Antony Pavlov



reply via email to

[Prev in Thread] Current Thread [Next in Thread]