[llvm-dev] asan for allocas on powerpc64

[Maxim Ostapenko via llvm-dev]

On 18/11/15 20:44, Yury Gribov wrote:
> On 11/18/2015 12:12 AM, Jay Foad wrote:
>>>>      Currently test/asan/TestCases/alloca_vla_interact.cc is 
>>>> XFAILed for
>>>>      powerpc64. I've had a look at why it doesn't work. I think the 
>>>> only
>>>>      problem is in the call to __asan_allocas_unpoison that is 
>>>> inserted at
>>>>      the end of the "for" loop (just before a stackrestore 
>>>> instruction).
>>>>
>>>>      The call function is created something like this (paraphrasing 
>>>> from
>>>>      lib/Transfoms/Instrumentation/AddressSanitizer.cpp):
>>>>
>>>>        // call __asan_allocas_unpoison(uptr top, uptr bottom);
>>>>        // NB "top" here means lowest address and "bottom" means 
>>>> highest!
>>>>
>>>>        IRB.CreateCall(
>>>>          AsanAllocasUnpoisonFunc,
>>>>          {
>>>>            IRB.CreateLoad(DynamicAllocaLayout),
>>>> IRB.CreatePointerToInt(SaveRestoreInst->getOperand(0), IntptrTy)
>>>>          }
>>>>        );
>>>>
>>>>      I think the problem is that the operand to stackrestore is the 
>>>> new
>>>>      native sp register value to restore, and this code is assuming 
>>>> that
>>>>      that will be a higher address than all the allocas that are being
>>>>      unallocated. But on PowerPC64, the native sp is always lower 
>>>> than the
>>>>      address of the most recent alloca by MaxCallFrameSize bytes, 
>>>> to leave
>>>>      space for outgoing call arguments. So I think the second 
>>>> argument to
>>>>      __asan_allocas_unpoison needs to be 
>>>> SaveRestoreInst->getOperand(0) +
>>>>      MaxCallFrameSize, but I don't know how to implement that.
>>>>
>>>>      Thoughts?
>>>>
>>>
>>> Yeah, you are right, we rely on stackrestore to get "bottom" 
>>> parameter for
>>> __asan_allocas_unpoison and indeed PowerPC64 seems to be special here.
>>> However, right now I don't see a suitable way how to get 
>>> MaxCallFrameSize
>>> from LLVM backend in ASan pass, investigation is in progress.
>>
>> One idea I had for a solution was to change llvm.stacksave so that it
>> *always* returned native sp + MaxCallFrameSize, and do the
>> corresponding adjustment in llvm.stackrestore. In most cases this
>> would just replace a mov instruction with an addi instruction.
>
> Another option is provide a builtin function like 
> getDynamicAreaOffset() (to be lowered in backends).

Yeah, thanks, this is the most general fix IMHO. For most targets, 
getDynamicAreaOffset() would be lowered to 0 (and probably optimized 
out), for PPC we would return MaxCallFrameSize.

>
>> I don't know if this would cause other problems, or if it would be
>> acceptable to the target maintainers.
>
>