[llvm-dev] asan for allocas on powerpc64
Maxim Ostapenko via llvm-dev
llvm-dev at lists.llvm.org
Wed Nov 18 10:25:49 PST 2015
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.
>
>
More information about the llvm-dev
mailing list