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