(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.
Kostya Serebryany via llvm-dev
2015-Nov-12 20:44 UTC
[llvm-dev] asan for allocas on powerpc64
+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. >> >
Maxim Ostapenko via llvm-dev
2015-Nov-17 18:03 UTC
[llvm-dev] asan for allocas on powerpc64
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