[PATCH] D105201: [hwasan] Detect use after scope within function.
Vitaly Buka via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Jul 16 12:53:22 PDT 2021
vitalybuka added inline comments.
================
Comment at: compiler-rt/test/hwasan/TestCases/stack-uas.c:10
+
+// RUN: %clang_hwasan -fexperimental-new-pass-manager -mllvm -hwasan-use-after-scope -g %s -o %t && not %run %t 2>&1 | FileCheck %s
+// RUN: %clang_hwasan -fno-experimental-new-pass-manager -mllvm -hwasan-use-after-scope -g %s -o %t && not %run %t 2>&1 | FileCheck %s
----------------
eugenis wrote:
> fmayer wrote:
> > eugenis wrote:
> > > fmayer wrote:
> > > > vitalybuka wrote:
> > > > > vitalybuka wrote:
> > > > > > It looks all these test ported version of asan
> > > > > > it would be nice if in a separate patch you commit them as exact copy (with XFAIL: *)
> > > > > >
> > > > > > so in D105201 we can see only change you need to make for HWASAN
> > > > > Actually compiler-rt should not be in this patch. Ideally two additional patches
> > > > > 1. D105201 only llvm/
> > > > > 2. I guess we will add proper clang fronted flag to avoid "-mllvm -hwasan-use-after-scope" ? similar -fsanitize-address-use-after-scope. Doing this before 4 will save one patch to replace them "-mllvm -hwasan-use-after-scope" -> -fsanitize-hwaddress-use-after-scope
> > > > > 3. Clone compiler-rt tests with XFAIL:*
> > > > > 4. Update and enable -hwasan-use-after-scope
> > > > >
> > > > > D105201 changes llvm/lib/Transforms/Instrumentation/, so we need tests in llvm/test/Instrumentation/, similar to AddressSanitizer/lifetime.ll
> > > > >
> > > > > if you move AArch64StackTagging.cpp into a separate refactoring NFC patch, it does not need new tests
> > > > >
> > > > Ad 2. I will let eugenis comment on that, but to me it seems a lot of the HWAsan feature flags are passed via -mllvm without any intention to make them first-class clang options. Especially given we want to make this the default soon (see the other comment thread between eugenis and me).
> > > Let's look at performance and code size impact first, but I'd like that to just be on all the time, and the -mllvm option can be used to opt out if something goes wrong.
> > >
> > > Note that memtag does not have a frontend flag for use-after-scope, either.
> > So is it okay to leave as is? I'll add an LLVM IR level test as well to this change.
> Yes. I'd rather not introduce a clang flag unless we know that there will be users who would want it both ways. We can not easily deprecate clang flags.
>
> Yes. I'd rather not introduce a clang flag unless we know that there will be users who would want it both ways. We can not easily deprecate clang flags.
OK
> So is it okay to leave as is? I'll add an LLVM IR level test as well to this change.
OK
================
Comment at: compiler-rt/test/hwasan/TestCases/use-after-scope-types.cpp:24
+template <class T>
+struct Ptr {
void Store(T *ptr) { t = ptr; }
----------------
fmayer wrote:
> i'll sort out the autoformatting diff.
That's would be great after D106159 and before this one
================
Comment at: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp:1294
// Replace uses of the alloca with tagged address.
- Value *Tag = getAllocaTag(IRB, StackTag, AI, N);
+ Value *Tag = getAllocaTag(IRB, StackTag, AI, ++N);
Value *AILong = IRB.CreatePointerCast(AI, IntptrTy);
----------------
Probably not important but now it's starts with N==1
================
Comment at: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp:1319
+ bool StandardLifetime = UnrecognizedLifetimes.empty() &&
+ Info.LifetimeStart.size() == 1 &&
+ Info.LifetimeEnd.size() == 1;
----------------
I guess asan handles multiple starts/ends?
================
Comment at: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp:1331
+ tagAlloca(IRB, AI, Tag, Size);
+ if (!forAllReachableExits(DT, PDT, Start, End, RetVec, TagEnd)) {
+ End->eraseFromParent();
----------------
{} unneeded
================
Comment at: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp:1476
+ if (LocalDT == nullptr) {
+ DeleteDT = std::make_unique<DominatorTree>(F);
+ LocalDT = DeleteDT.get();
----------------
why we need these empty Trees?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D105201/new/
https://reviews.llvm.org/D105201
More information about the llvm-commits
mailing list