maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/ubsan-devirtualized-calls.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

89 lines
4.0 KiB
C++
Raw Normal View History

[ubsan] Null-check pointers in -fsanitize=vptr (PR33881) The instrumentation generated by -fsanitize=vptr does not null check a user pointer before loading from it. This causes crashes in the face of UB member calls (this=nullptr), i.e it's causing user programs to crash only after UBSan is turned on. The fix is to make run-time null checking a prerequisite for enabling -fsanitize=vptr, and to then teach UBSan to reuse these run-time null checks to make -fsanitize=vptr safe. Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build Differential Revision: https://reviews.llvm.org/D35735 https://bugs.llvm.org/show_bug.cgi?id=33881 llvm-svn: 309007
2017-07-26 03:34:23 +08:00
// RUN: %clang_cc1 -std=c++11 -triple %itanium_abi_triple -emit-llvm -fsanitize=null,vptr %s -o - | FileCheck %s
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
struct Base1 {
virtual void f1() {}
};
struct Base2 {
virtual void f1() {}
};
struct Derived1 final : Base1 {
void f1() override {}
};
struct Derived2 final : Base1, Base2 {
void f1() override {}
};
struct Derived3 : Base1 {
void f1() override /* nofinal */ {}
};
struct Derived4 final : Base1 {
void f1() override final {}
};
// CHECK: [[UBSAN_TI_DERIVED1_1:@[0-9]+]] = private unnamed_addr global {{.*}} i8* bitcast {{.*}} @_ZTI8Derived1 to i8*
// CHECK: [[UBSAN_TI_DERIVED2_1:@[0-9]+]] = private unnamed_addr global {{.*}} i8* bitcast {{.*}} @_ZTI8Derived2 to i8*
// CHECK: [[UBSAN_TI_DERIVED2_2:@[0-9]+]] = private unnamed_addr global {{.*}} i8* bitcast {{.*}} @_ZTI8Derived2 to i8*
[CodeGen] Devirtualize calls to methods marked final in a derived class If we see a virtual method call to Base::foo() but can infer that the object is an instance of Derived, and that 'foo' is marked 'final' in Derived, we can devirtualize the call to Derived::foo(). Differential Revision: https://reviews.llvm.org/D25813 llvm-svn: 284766
2016-10-21 02:44:14 +08:00
// CHECK: [[UBSAN_TI_DERIVED3:@[0-9]+]] = private unnamed_addr global {{.*}} i8* bitcast {{.*}} @_ZTI8Derived3 to i8*
// CHECK: [[UBSAN_TI_BASE1:@[0-9]+]] = private unnamed_addr global {{.*}} i8* bitcast {{.*}} @_ZTI5Base1 to i8*
// CHECK: [[UBSAN_TI_DERIVED4_1:@[0-9]+]] = private unnamed_addr global {{.*}} i8* bitcast {{.*}} @_ZTI8Derived4 to i8*
// CHECK: [[UBSAN_TI_DERIVED4_2:@[0-9]+]] = private unnamed_addr global {{.*}} i8* bitcast {{.*}} @_ZTI8Derived4 to i8*
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK-LABEL: define {{(dso_local )?}}void @_Z2t1v
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
void t1() {
Derived1 d1;
static_cast<Base1 *>(&d1)->f1(); //< Devirt Base1::f1 to Derived1::f1.
[ubsan] Drop dependency on a 64-bit arch in a test (NFC) This should fix: http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/46184 llvm-svn: 284642
2016-10-20 04:53:16 +08:00
// CHECK: %[[D1:[0-9]+]] = ptrtoint %struct.Derived1* %d1 to i{{[0-9]+}}, !nosanitize
// CHECK-NEXT: call void @__ubsan_handle_dynamic_type_cache{{[_a-z]*}}({{.*}} [[UBSAN_TI_DERIVED1_1]] {{.*}}, i{{[0-9]+}} %[[D1]]
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK-LABEL: define {{(dso_local )?}}void @_Z2t2v
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
void t2() {
Derived2 d2;
static_cast<Base1 *>(&d2)->f1(); //< Devirt Base1::f1 to Derived2::f1.
[ubsan] Drop dependency on a 64-bit arch in a test (NFC) This should fix: http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/46184 llvm-svn: 284642
2016-10-20 04:53:16 +08:00
// CHECK: %[[D2_1:[0-9]+]] = ptrtoint %struct.Derived2* %d2 to i{{[0-9]+}}, !nosanitize
// CHECK-NEXT: call void @__ubsan_handle_dynamic_type_cache{{[_a-z]*}}({{.*}} [[UBSAN_TI_DERIVED2_1]] {{.*}}, i{{[0-9]+}} %[[D2_1]]
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK-LABEL: define {{(dso_local )?}}void @_Z2t3v
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
void t3() {
Derived2 d2;
static_cast<Base2 *>(&d2)->f1(); //< Devirt Base2::f1 to Derived2::f1.
[ubsan] Drop dependency on a 64-bit arch in a test (NFC) This should fix: http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/46184 llvm-svn: 284642
2016-10-20 04:53:16 +08:00
// CHECK: %[[D2_2:[0-9]+]] = ptrtoint %struct.Derived2* %d2 to i{{[0-9]+}}, !nosanitize
// CHECK-NEXT: call void @__ubsan_handle_dynamic_type_cache{{[_a-z]*}}({{.*}} [[UBSAN_TI_DERIVED2_2]] {{.*}}, i{{[0-9]+}} %[[D2_2]]
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK-LABEL: define {{(dso_local )?}}void @_Z2t4v
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
void t4() {
Base1 p;
Derived3 *badp = static_cast<Derived3 *>(&p); //< Check that &p isa Derived3.
[CodeGen] Devirtualize calls to methods marked final in a derived class If we see a virtual method call to Base::foo() but can infer that the object is an instance of Derived, and that 'foo' is marked 'final' in Derived, we can devirtualize the call to Derived::foo(). Differential Revision: https://reviews.llvm.org/D25813 llvm-svn: 284766
2016-10-21 02:44:14 +08:00
// CHECK: %[[P1:[0-9]+]] = ptrtoint %struct.Derived3* {{%[0-9]+}} to i{{[0-9]+}}, !nosanitize
// CHECK-NEXT: call void @__ubsan_handle_dynamic_type_cache{{[_a-z]*}}({{.*}} [[UBSAN_TI_DERIVED3]] {{.*}}, i{{[0-9]+}} %[[P1]]
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
static_cast<Base1 *>(badp)->f1(); //< No devirt, test 'badp isa Base1'.
[ubsan] Null-check pointers in -fsanitize=vptr (PR33881) The instrumentation generated by -fsanitize=vptr does not null check a user pointer before loading from it. This causes crashes in the face of UB member calls (this=nullptr), i.e it's causing user programs to crash only after UBSan is turned on. The fix is to make run-time null checking a prerequisite for enabling -fsanitize=vptr, and to then teach UBSan to reuse these run-time null checks to make -fsanitize=vptr safe. Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build Differential Revision: https://reviews.llvm.org/D35735 https://bugs.llvm.org/show_bug.cgi?id=33881 llvm-svn: 309007
2017-07-26 03:34:23 +08:00
// We were able to skip the null check on the first type check because 'p'
// is backed by an alloca. We can't skip the second null check because 'badp'
// is a (bitcast (load ...)).
// CHECK: call void @__ubsan_handle_type_mismatch
//
[CodeGen] Devirtualize calls to methods marked final in a derived class If we see a virtual method call to Base::foo() but can infer that the object is an instance of Derived, and that 'foo' is marked 'final' in Derived, we can devirtualize the call to Derived::foo(). Differential Revision: https://reviews.llvm.org/D25813 llvm-svn: 284766
2016-10-21 02:44:14 +08:00
// CHECK: %[[BADP1:[0-9]+]] = ptrtoint %struct.Base1* {{%[0-9]+}} to i{{[0-9]+}}, !nosanitize
// CHECK-NEXT: call void @__ubsan_handle_dynamic_type_cache{{[_a-z]*}}({{.*}} [[UBSAN_TI_BASE1]] {{.*}}, i{{[0-9]+}} %[[BADP1]]
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK-LABEL: define {{(dso_local )?}}void @_Z2t5v
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
void t5() {
Base1 p;
Derived4 *badp = static_cast<Derived4 *>(&p); //< Check that &p isa Derived4.
[CodeGen] Devirtualize calls to methods marked final in a derived class If we see a virtual method call to Base::foo() but can infer that the object is an instance of Derived, and that 'foo' is marked 'final' in Derived, we can devirtualize the call to Derived::foo(). Differential Revision: https://reviews.llvm.org/D25813 llvm-svn: 284766
2016-10-21 02:44:14 +08:00
// CHECK: %[[P1:[0-9]+]] = ptrtoint %struct.Derived4* {{%[0-9]+}} to i{{[0-9]+}}, !nosanitize
// CHECK-NEXT: call void @__ubsan_handle_dynamic_type_cache{{[_a-z]*}}({{.*}} [[UBSAN_TI_DERIVED4_1]] {{.*}}, i{{[0-9]+}} %[[P1]]
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
static_cast<Base1 *>(badp)->f1(); //< Devirt Base1::f1 to Derived4::f1.
[ubsan] Null-check pointers in -fsanitize=vptr (PR33881) The instrumentation generated by -fsanitize=vptr does not null check a user pointer before loading from it. This causes crashes in the face of UB member calls (this=nullptr), i.e it's causing user programs to crash only after UBSan is turned on. The fix is to make run-time null checking a prerequisite for enabling -fsanitize=vptr, and to then teach UBSan to reuse these run-time null checks to make -fsanitize=vptr safe. Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build Differential Revision: https://reviews.llvm.org/D35735 https://bugs.llvm.org/show_bug.cgi?id=33881 llvm-svn: 309007
2017-07-26 03:34:23 +08:00
// CHECK: call void @__ubsan_handle_type_mismatch
//
[CodeGen] Devirtualize calls to methods marked final in a derived class If we see a virtual method call to Base::foo() but can infer that the object is an instance of Derived, and that 'foo' is marked 'final' in Derived, we can devirtualize the call to Derived::foo(). Differential Revision: https://reviews.llvm.org/D25813 llvm-svn: 284766
2016-10-21 02:44:14 +08:00
// CHECK: %[[BADP1:[0-9]+]] = ptrtoint %struct.Derived4* {{%[0-9]+}} to i{{[0-9]+}}, !nosanitize
// CHECK-NEXT: call void @__ubsan_handle_dynamic_type_cache{{[_a-z]*}}({{.*}} [[UBSAN_TI_DERIVED4_2]] {{.*}}, i{{[0-9]+}} %[[BADP1]]
[ubsan] Use the object pointer's type info for devirtualized calls ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
2016-10-20 04:21:16 +08:00
}