llvm dev - Nov 2015 - Fwd: asan for allocas on powerpc64

(Resending with the correct mailing list address.)

Hi,

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?

Thanks,
Jay.

+Maxim and Yuri, as I think this is their code.

On Thu, Nov 12, 2015 at 3:02 AM, Jay Foad <jay.foad at gmail.com> wrote:
> (Resending with the correct mailing list address.)
>
> Hi,
>
> 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?
>
> Thanks,
> Jay.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151112/3386c36d/attachment.html>

----- Original Message -----
> From: "Jay Foad" <jay.foad at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>, "Kostya
Serebryany" <kcc at google.com>, llvm-dev at lists.llvm.org
> Sent: Thursday, November 12, 2015 5:02:42 AM
> Subject: Fwd: asan for allocas on powerpc64
> 
> (Resending with the correct mailing list address.)
> 
> Hi,
> 
> 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?
FWIW, there is a diagram here:

  http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#DYNAM-STACK

 -Hal
> 
> Thanks,
> Jay.
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

Thanks for the investigation, we'll check on Monday.

On 11/12/2015 11:44 PM, Kostya Serebryany wrote:
> +Maxim and Yuri, as I think this is their code.
>
> On Thu, Nov 12, 2015 at 3:02 AM, Jay Foad <jay.foad at gmail.com>
wrote:
>
>> (Resending with the correct mailing list address.)
>>
>> Hi,
>>
>> 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?
>>
>> Thanks,
>> Jay.
>>
>

Hi!

Sorry for delay, just returned from vacation.

On 12/11/15 23:44, Kostya Serebryany via llvm-dev wrote:
> +Maxim and Yuri, as I think this is their code.
>
> On Thu, Nov 12, 2015 at 3:02 AM, Jay Foad <jay.foad at gmail.com 
> <mailto:jay.foad at gmail.com>> wrote:
>
>     (Resending with the correct mailing list address.)
>
>     Hi,
>
>     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.

Thank you again for spending your time on this!

-Maxim
>     Thanks,
>     Jay.
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev