[Top][All Lists]

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

Re: [Qemu-ppc] [Qemu-devel] Help needed testing on ppc

From: Alexander Graf
Subject: Re: [Qemu-ppc] [Qemu-devel] Help needed testing on ppc
Date: Mon, 23 Jun 2014 19:07:12 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 19.06.14 15:21, BALATON Zoltan wrote:
On Wed, 18 Jun 2014, Tom Musta wrote:
On 6/17/2014 10:17 AM, BALATON Zoltan wrote:
On Tue, 17 Jun 2014, Tom Musta wrote:
I am looking at the test case source code and do not see how you are setting the reserved bit. Maybe I am missing some cleverness in how the test is built?

Probably I should have written it more straight-forward but I wanted it to be possible to change it for other tests easily so it's a bit tricky. Basically I get the code location by a bl then fetching the link register:

 asm volatile("mfcr %0 \n\t"
              "bl 1f                 \n\t"
              "mfcr %1               \n\t"
              "mflr 10               \n\t"

and then set the bit with the next three lines after testing the normal case:

              "lwz %0, 36(10) \n\t"
              "ori %0, %0, 1         \n\t"
              "stw %0, 36(10)        \n\t"

Then test again with the bit set:

              "mfcr %0 \n\t"
              "bl 1f                 \n\t"
              "mfcr %2               \n\t"

and exit:

              "b 2f \n\t"
"1: stwx %0, %4, %6 \n\t" <<<<<<<<<<<<< just a normal stwx, right?
              "blr                   \n\t"
              "2:                    \n\t"
               : "=&r"(cr), "=&r"(cr1), "=&r"(cr2), "=m"(val)
               : "r"(&val), "m"(val), "r"(8)
               : "r8", "r9", "r10", "cc", "memory");

 prom_printf("old cr  (mem):\t%#x\n", val);
 prom_printf("old cr  (reg):\t%#x\n", cr);
 prom_printf("new cr1 (reg):\t%#x\n", cr1);
 prom_printf("new cr2 (reg):\t%#x\n", cr2);

But the objdump of your test binary does not show that it is set either:

It should show in a debugger the second time the stwx is called (it did for me).

There should be an icbi after the ori/stw sequence to ensure that the modified code gets into the instruction cache.

I've corrected the test accordingly and rerun on iMac,1. It did not change the stwx test results, the cr values are still the same.

Great :). Now please check through all opcodes that get generated by the GEN_STUX, GEN_STX_E, GEN_LDUX and GEN_LDX_E helpers in translate.c and verify that the bit gets ignored on all of them. We can then easily just remove the reserved Rc bit on those instruction definitions generically and call it a day.


reply via email to

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