ignore -mconstructor-aliases when adding field paddings for asan

[kcc]

Summary

When we are adding field paddings for asan even an empty dtor has to remain in the code,
so we ignore -mconstructor-aliases if the paddings are going to be added.

[rnk]

Rafael was touching this last.

Why do we have to avoid aliasing? Note that there are many "aliasing" strategies here: RAUW, normal alias, and aliases in D5 comdat groups.

[kcc]

We need to emit the actual DTOR instead of replacing it with the base class DTOR, because later in clang codegen this DTOR will be instrumented with __asan_unpoison_intra_object_redzone and its body will become non-empty

[rnk]

No, even if the target dtor is implemented the derived class will have
extra padding it needs to unpoison. Consider:

struct A {

virtual ~A();
int x[1];
int y[1];

};
struct B {

virtual ~B();
int z[1];
int w[1];

};
B::~B() {}

The B dtor must unpoison the padding between z and w.

[• rafael]

LGTM with rnk's example and explanation added to a testcase.

lib/CodeGen/CGCXX.cpp

bool CodeGenModule::TryEmitBaseDestructorAsAlias(const CXXDestructorDecl *D) {
 
   // If the destructor doesn't have a trivial body, we have to emit it
   // separately.
   if (!D->hasTrivialBody())
     return true;
 
   const CXXRecordDecl *Class = D->getParent();
 
+  // We are going to instrument this destructor, so give up even if it is
+  // currently empty.
+  if (Class->mayInsertExtraPadding())
+    return true;
+
   // If we need to manipulate a VTT parameter, give up.
   if (Class->getNumVBases()) {
     // Extra Credit:  passing extra parameters is perfectly safe
     // in many calling conventions, so only bail out if the ctor's
     // calling convention is nonstandard.
     return true;
   }
 

test/CodeGen/sanitize-address-field-padding.cpp

 // Test -fsanitize-address-field-padding
 // RUN: echo 'type:SomeNamespace::BlacklistedByName=field-padding' > %t.type.blacklist
 // RUN: echo 'src:*sanitize-address-field-padding.cpp=field-padding' > %t.file.blacklist
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsanitize=address -fsanitize-address-field-padding=1 -fsanitize-blacklist=%t.type.blacklist -Rsanitize-address -emit-llvm -o - %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsanitize=address -fsanitize-address-field-padding=1 -fsanitize-blacklist=%t.type.blacklist -Rsanitize-address -emit-llvm -o - %s -O1 -mconstructor-aliases 2>&1 | FileCheck %s --check-prefix=WITH_CTOR_ALIASES
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsanitize=address -fsanitize-address-field-padding=1 -fsanitize-blacklist=%t.file.blacklist -Rsanitize-address -emit-llvm -o - %s 2>&1 | FileCheck %s --check-prefix=FILE_BLACKLIST
 // RUN: %clang_cc1 -fsanitize=address -emit-llvm -o - %s 2>&1 | FileCheck %s --check-prefix=NO_PADDING
 // REQUIRES: shell
 //
 
 // The reasons to ignore a particular class are not set in stone and will change.
 //
 // CHECK: -fsanitize-address-field-padding applied to Positive1

 //
 // CHECK-LABEL: define linkonce_odr void @_ZN20ClassWithVirtualBaseC1Ev
 // CHECK: call void @__asan_poison_intra_object_redzone({{.*}} 12)
 // CHECK: call void @__asan_poison_intra_object_redzone({{.*}} 9)
 // CHECK: call void @__asan_poison_intra_object_redzone({{.*}} 15)
 // CHECK-NOT: __asan_poison_intra_object_redzone
 // CHECK: ret void
 //
+
+struct WithVirtualDtor { virtual ~WithVirtualDtor(); };
+struct InheritsFrom_WithVirtualDtor: WithVirtualDtor {
+  int a;
+  InheritsFrom_WithVirtualDtor() {}
+  ~InheritsFrom_WithVirtualDtor() {}
+};
+
+void Create_InheritsFrom_WithVirtualDtor() {
+  InheritsFrom_WithVirtualDtor x;
+}
+
+
+// Make sure the dtor of InheritsFrom_WithVirtualDtor remains in the code,
+// i.e. we ignore -mconstructor-aliases when field paddings are added.
+// WITH_CTOR_ALIASES-LABEL: define void @_Z35Create_InheritsFrom_WithVirtualDtor
+// WITH_CTOR_ALIASES-NOT: call void @_ZN15WithVirtualDtorD2Ev
+// WITH_CTOR_ALIASES: call void @_ZN28InheritsFrom_WithVirtualDtorD2Ev
+// WITH_CTOR_ALIASES: ret void