<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 December 2014 at 13:50, Sasa Stankovic <span dir="ltr"><<a href="mailto:Sasa.Stankovic@imgtec.com" target="_blank">Sasa.Stankovic@imgtec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes. Currently two tests fail because of the redundant sandboxing - syscall_return_sandboxing_test and exception_test. For syscall_return_sandboxing_test, to make the test pass we can either remove sandboxing from the assembly, or apply this patch.</blockquote><div><br></div><div>In that case, removing the sandboxing from the assembly makes sense.  That's the reason for implementing auto-sandboxing:  assembly code shouldn't need any explicit sandboxing instructions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For exception test, neither removing the sandboxing nor applying the patch will work. Here is the problematic inline assembly from exception_test.c file:<br>
<br>
crash_at_known_address:<br>
and $zero, $zero, $t7<br>
prog_ctr_at_crash:<br>
sw $t0, 0($zero)<br></blockquote><div><br></div><div>Incidentally, it's funny that the MIPS validator allows that instruction sequence.  The "and" is a no-op, because modifying $zero has no effect.  The validator could safely allow "sw ..., 0($zero)" on its own as a "crash instruction".  (BTW, I am not recommending changing the validator to do that!)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
exception_test works by crashing when executing instruction labeled by "prog_ctr_at_crash", and then checking whether the saved program counter is identical to the value of "prog_ctr_at_crash". Test currently fails because sandboxing will add mask before "sw", moving the "sw" to the address prog_ctr_at_crash + 4. Removing the mask in the assembly obviously wouldn't make the test pass. But even with the patch applied this test would still fail. That's because patch is implemented so that it first saves the mask, and then emits it when emitting next instruction, surrounded by BundleLock() and BundleUnlock(). So patch would first save mask, then emit label "prog_ctr_at_crash", and then emit mask and "sw", placing "sw" at address prog_ctr_at_crash + 4.<br></blockquote><div><br></div><div>OK, the key point is that the LLVM patch doesn't fix this test case. :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The only way to make exception_test pass is either to add #ifdef for MIPS that would check that program counter has value prog_ctr_at_crash + 4,</blockquote><div><br></div><div>That would be reasonable.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">or find instruction that doesn't require masking and that can cause program to crash.<br></blockquote><div><br></div><div>That would be better.  Is there a MIPS breakpoint/trap instruction that would work here?  (ARM's breakpoints/traps are complicated under NaCl.  I can't remember how MIPS compares.)</div><div><br></div><div>Alternatively you can do memory accesses via sp without a mask, because sp is pre-masked.  Something like this should work:</div><div><br></div><div>mov $sp, $zero</div><div>prog_ctr_at_crash:</div><div>sw $t0, ($sp)</div><div><br></div><div>Cheers,</div><div>Mark</div><div><br></div></div></div></div>