<div dir="ltr">In LowerGET_DYNAMIC_AREA_OFFSET() you're calling MFI->getMaxCallFrameSize(), but it looks like that doesn't return useful information until after the PrologEpilogInserter's PEI::calculateCallsInformation() has run.<div><br></div><div>So maybe the lowering has to be done as part of frame index elimination? (I'm not too familiar with this code.)</div><div><br></div><div>Jay.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 November 2015 at 13:07, Jay Foad <span dir="ltr"><<a href="mailto:jay.foad@gmail.com" target="_blank">jay.foad@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Maxim,<div><br></div><div>It seems to be doing roughly the right thing, but it isn't quite enough to fix the test case. getDynamicAreaOffset() is returning 0x20, but from looking at the generated code for the test case, the real offset from native sp to the allocated area is 0x60.</div><div><br></div><div>I will run it under gdb and see if I can spot the problem...</div><div><br></div><div>Thanks!</div><span class="HOEnZb"><font color="#888888"><div>Jay.</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 23 November 2015 at 11:41, Maxim Ostapenko <span dir="ltr"><<a href="mailto:m.ostapenko@partner.samsung.com" target="_blank">m.ostapenko@partner.samsung.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jay, do you have a PowerPC64 target? If so, could you please check attached patch on PPC box? This is a draft patch, but it would be nice to make sure that we are moving to right direction here.<br>
<br>
Thanks,<br>
-Maxim<div><div><br>
<br>
On 18/11/15 00:12, Jay Foad wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
     Currently test/asan/TestCases/alloca_vla_interact.cc is XFAILed for<br>
     powerpc64. I've had a look at why it doesn't work. I think the only<br>
     problem is in the call to __asan_allocas_unpoison that is inserted at<br>
     the end of the "for" loop (just before a stackrestore instruction).<br>
<br>
     The call function is created something like this (paraphrasing from<br>
     lib/Transfoms/Instrumentation/AddressSanitizer.cpp):<br>
<br>
       // call __asan_allocas_unpoison(uptr top, uptr bottom);<br>
       // NB "top" here means lowest address and "bottom" means highest!<br>
<br>
       IRB.CreateCall(<br>
         AsanAllocasUnpoisonFunc,<br>
         {<br>
           IRB.CreateLoad(DynamicAllocaLayout),<br>
     IRB.CreatePointerToInt(SaveRestoreInst->getOperand(0), IntptrTy)<br>
         }<br>
       );<br>
<br>
     I think the problem is that the operand to stackrestore is the new<br>
     native sp register value to restore, and this code is assuming that<br>
     that will be a higher address than all the allocas that are being<br>
     unallocated. But on PowerPC64, the native sp is always lower than the<br>
     address of the most recent alloca by MaxCallFrameSize bytes, to leave<br>
     space for outgoing call arguments. So I think the second argument to<br>
     __asan_allocas_unpoison needs to be SaveRestoreInst->getOperand(0) +<br>
     MaxCallFrameSize, but I don't know how to implement that.<br>
<br>
     Thoughts?<br>
<br>
</blockquote>
Yeah, you are right, we rely on stackrestore to get "bottom" parameter for<br>
__asan_allocas_unpoison and indeed PowerPC64 seems to be special here.<br>
However, right now I don't see a suitable way how to get MaxCallFrameSize<br>
from LLVM backend in ASan pass, investigation is in progress.<br>
</blockquote>
One idea I had for a solution was to change llvm.stacksave so that it<br>
*always* returned native sp + MaxCallFrameSize, and do the<br>
corresponding adjustment in llvm.stackrestore. In most cases this<br>
would just replace a mov instruction with an addi instruction.<br>
<br>
I don't know if this would cause other problems, or if it would be<br>
acceptable to the target maintainers.<br>
<br>
Jay.<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>