qemu-devel
[Top][All Lists]
Advanced

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

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


From: BALATON Zoltan
Subject: Re: [Qemu-devel] [Qemu-ppc] Help needed testing on ppc
Date: Thu, 19 Jun 2014 15:21:56 +0200 (CEST)
User-agent: Alpine 2.02 (LMD 1266 2009-07-14)

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.

Regards,
BALATON Zoltan




reply via email to

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