[test][asan] Check for order of DynInitPoison

[vitalybuka]

Also make sure we have dynamic init variables with any -O.

[llvmbot]

@llvm/pr-subscribers-compiler-rt-sanitizer

Author: Vitaly Buka (vitalybuka)

Changes

Also make sure we have dynamic init variables with any -O.

---

Full diff: https://github.com/llvm/llvm-project/pull/101584.diff

2 Files Affected:

• (modified) compiler-rt/test/asan/TestCases/Helpers/initialization-nobug-extra.cpp (+3-3)
• (modified) compiler-rt/test/asan/TestCases/initialization-nobug.cpp (+9-8)

diff --git a/compiler-rt/test/asan/TestCases/Helpers/initialization-nobug-extra.cpp b/compiler-rt/test/asan/TestCases/Helpers/initialization-nobug-extra.cpp
index 886165affd760..0ce5359b405d0 100644
--- a/compiler-rt/test/asan/TestCases/Helpers/initialization-nobug-extra.cpp
+++ b/compiler-rt/test/asan/TestCases/Helpers/initialization-nobug-extra.cpp
@@ -1,9 +1,9 @@
 // Linker initialized:
 int getAB();
-static int ab = getAB();
+int ab = getAB();
 // Function local statics:
 int countCalls();
-static int one = countCalls();
+int one = countCalls();
 // Trivial constructor, non-trivial destructor:
 int getStructWithDtorValue();
-static int val = getStructWithDtorValue();
+int val = getStructWithDtorValue();
diff --git a/compiler-rt/test/asan/TestCases/initialization-nobug.cpp b/compiler-rt/test/asan/TestCases/initialization-nobug.cpp
index d4dc855148ad3..0b8fca3dee8b3 100644
--- a/compiler-rt/test/asan/TestCases/initialization-nobug.cpp
+++ b/compiler-rt/test/asan/TestCases/initialization-nobug.cpp
@@ -1,19 +1,16 @@
 // A collection of various initializers which shouldn't trip up initialization
 // order checking.  If successful, this will just return 0.
 
-// RUN: %clangxx_asan -O0 %s %p/Helpers/initialization-nobug-extra.cpp -o %t
-// RUN: %env_asan_opts=check_initialization_order=true %run %t 2>&1
-// RUN: %clangxx_asan -O1 %s %p/Helpers/initialization-nobug-extra.cpp -o %t
-// RUN: %env_asan_opts=check_initialization_order=true %run %t 2>&1
-// RUN: %clangxx_asan -O2 %s %p/Helpers/initialization-nobug-extra.cpp -o %t
-// RUN: %env_asan_opts=check_initialization_order=true %run %t 2>&1
-// RUN: %clangxx_asan -O3 %s %p/Helpers/initialization-nobug-extra.cpp -o %t
-// RUN: %env_asan_opts=check_initialization_order=true %run %t 2>&1
+// RUN: %clangxx_asan -O0 %s %p/Helpers/initialization-nobug-extra.cpp -o %t && %env_asan_opts=check_initialization_order=true:report_globals=3 %run %t 2>&1 | FileCheck %s --implicit-check-not "DynInit"
+// RUN: %clangxx_asan -O1 %s %p/Helpers/initialization-nobug-extra.cpp -o %t && %env_asan_opts=check_initialization_order=true:report_globals=3 %run %t 2>&1 | FileCheck %s --implicit-check-not "DynInit"
+// RUN: %clangxx_asan -O2 %s %p/Helpers/initialization-nobug-extra.cpp -o %t && %env_asan_opts=check_initialization_order=true:report_globals=3 %run %t 2>&1 | FileCheck %s --implicit-check-not "DynInit"
+// RUN: %clangxx_asan -O3 %s %p/Helpers/initialization-nobug-extra.cpp -o %t && %env_asan_opts=check_initialization_order=true:report_globals=3 %run %t 2>&1 | FileCheck %s --implicit-check-not "DynInit"
 
 // Simple access:
 // Make sure that accessing a global in the same TU is safe
 
 bool condition = true;
+__attribute__((noinline, weak))
 int initializeSameTU() {
   return condition ? 0x2a : 052;
 }
@@ -46,3 +43,7 @@ StructWithDtor struct_with_dtor;
 int getStructWithDtorValue() { return struct_with_dtor.value; }
 
 int main() { return 0; }
+
+
+// CHECK: DynInitPoison module: {{.*}}initialization-nobug.cpp
+// CHECK: DynInitPoison module: {{.*}}initialization-nobug-extra.cpp

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[mstorsjo]

These new tests seem to fail on mingw targets - see https://github.com/mstorsjo/llvm-mingw/actions/runs/10223903341/job/28296084101 for a failed run.

It looks like the output is

DynInitPoison module: D:\a\llvm-mingw\llvm-mingw\llvm-project\compiler-rt\test\asan\TestCases/Helpers/initialization-nobug-extra.cpp
DynInitUnpoison
DynInitPoison module: D:\a\llvm-mingw\llvm-mingw\llvm-project\compiler-rt\test\asan\TestCases\initialization-nobug.cpp
DynInitUnpoison

while we expect them to come in the reverse order.

So I guess that sounds like a real bug on this target (CC @alvinhochun) - I guess we'll need to XFAIL this target in the test to keep the testsuite running though.

[alvinhochun]

This looks like the test is expecting the static initialization to be done in a specific order (first initialization-nobug.cpp then initialization-nobug-extra.cpp), but the order of static initialization in different TUs is unspecified, isn't it? So it doesn't seem to be a bug with the mingw-w64 target, just that the ordering of functions in the combined .ctors section and that the list is executed backwards on mingw-w64 CRT, is making it behave differently compared to Linux and even MSVC targets.

[mstorsjo]

This looks like the test is expecting the static initialization to be done in a specific order (first initialization-nobug.cpp then initialization-nobug-extra.cpp), but the order of static initialization in different TUs is unspecified, isn't it? So it doesn't seem to be a bug with the mingw-w64 target, just that the ordering of functions in the combined .ctors section and that the list is executed backwards on mingw-w64 CRT, is making it behave differently compared to Linux and even MSVC targets.

Thanks! So if we could make the test tolerate these two lines in any order (CHECK-DAG: maybe?), it'd work? But that's probably a bit harder when we want to check that we have the DynInitUnpoison lines inbetween...

[alvinhochun]

Though thinking about it, aren't these DynInitPoison stuff supposed to catch static initialization order fiasco? If they end up being interleaved together with regular C++ dynamic initialization then it seems it won't actually catch anything, which may indeed be a bug.

I thought the ASan runtime use the CRT sections .CRT$XIA~.CRT$XIZ (or something like that) to initialize things? Those should be executed before .ctors, no?

Edit: Perhaps I misunderstood how it is supposed to work. I probably have to check the code again...

Edit: Rechecked that __asan_before_dynamic_init is supposed to be called before the dynamic initialization in each TU and seeing from the log output of https://github.com/mstorsjo/llvm-mingw/actions/runs/10223903341/job/28296084101 that all Added Global lines are above the DynInitPoison/DynInitUnpoison lines, I am convinced this is working as expected. Sorry for the noise.

[vitalybuka]

Of cause we don't care about particular order of DynInitPoison.
Fixing.

Thanks!

[mstorsjo]

Of cause we don't care about particular order of DynInitPoison. Fixing.

Thanks!

Thanks for the quick fix!