[asan,test] Disable _FORTIFY_SOURCE test incompatible with glibc 2.40

[MaskRay]

In terms of bug catching capability, _FORTIFY_SOURCE does not perform
as well as some dynamic instrumentation tools. When a sanitizer is used,
generally _FORTIFY_SOURCE should be disabled since sanitizer runtime
does not implement most *_chk functions. Using _FORTIFY_SOURCE
will regress error checking (asan/hwasan/tsan) or cause false positives
(msan).

*printf_chk are the most pronounced _chk interceptors for
uninstrumented DSOes (https://reviews.llvm.org/D40951).

glibc 2.40 introduced pass_object_info style fortified source for some
functions (1). fprintf will be mangled as
_ZL7fprintfP8_IO_FILEU17pass_object_size1PKcz, which has no associated
interceptor, leading to printf-fortify-5.c failure.

Just disable the test. Fix #100877

[llvmbot]

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

Author: Fangrui Song (MaskRay)

Changes

In terms of bug catching capability, _FORTIFY_SOURCE does not perform
as well as some dynamic instrumentation tools. When a sanitizer is used,
generally _FORTIFY_SOURCE should be disabled since sanitizer runtime
does not implemented most *_chk functions. Using _FORTIFY_SOURCE
will regress error checking (asan/hwasan/tsan) or cause false positives
(msan).

*printf_chk are the most pronounced _chk interceptors for
uninstrumented DSOes (https://reviews.llvm.org/D40951).

glibc 2.40 introduced pass_object_info style fortified source for some
functions (1). fprintf will be mangled as
_ZL7fprintfP8_IO_FILEU17pass_object_size1PKcz, which has no associated
interceptor, leading to printf-fortify-5.c failure.

Just disable the test. Fix #100877

---

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

2 Files Affected:

• (modified) compiler-rt/test/asan/TestCases/Linux/printf-fortify-5.c (+2-1)
• (modified) compiler-rt/test/lit.common.cfg.py (+1-1)

diff --git a/compiler-rt/test/asan/TestCases/Linux/printf-fortify-5.c b/compiler-rt/test/asan/TestCases/Linux/printf-fortify-5.c
index c7522e4029ea1..86cf4ab0c9a22 100644
--- a/compiler-rt/test/asan/TestCases/Linux/printf-fortify-5.c
+++ b/compiler-rt/test/asan/TestCases/Linux/printf-fortify-5.c
@@ -1,7 +1,8 @@
 // RUN: %clang -fPIC -shared -O2 -D_FORTIFY_SOURCE=2 -D_DSO %s -o %t.so
 // RUN: %clang_asan -o %t %t.so %s
 // RUN: not %run %t 2>&1 | FileCheck %s
-// REQUIRES: glibc-2.27
+/// Incompatible with pass_object_info style fortified source since glibc 2.40.
+// REQUIRES: glibc-2.27 && !glibc-2.40
 #ifdef _DSO
 #include <stdio.h>
 #include <stdlib.h>
diff --git a/compiler-rt/test/lit.common.cfg.py b/compiler-rt/test/lit.common.cfg.py
index 70bf43e2fac59..281258ea7baf5 100644
--- a/compiler-rt/test/lit.common.cfg.py
+++ b/compiler-rt/test/lit.common.cfg.py
@@ -674,7 +674,7 @@ def add_glibc_versions(ver_string):
 
         ver = LooseVersion(ver_string)
         any_glibc = False
-        for required in ["2.19", "2.27", "2.30", "2.33", "2.34", "2.37", "2.38"]:
+        for required in ["2.19", "2.27", "2.30", "2.33", "2.34", "2.37", "2.38", "2.40"]:
             if ver >= LooseVersion(required):
                 config.available_features.add("glibc-" + required)
                 any_glibc = True

[github-actions]

✅ With the latest revision this PR passed the Python code formatter.

[mgorny]

Thanks for the detailed analysis and the patch!

[thesamesam]

LGTM but give azanella a chance to comment (or be prepared to followup on comment afterwards). Thanks for digging into it. We should really run the compiler-rt testsuite before glibc releases given how often this sort of thing happens.

[zatrazz]

LGTM to me as well, but I wonder how hard would to make sanitizer work properly with forfity calls (maybe just bypass them to internal fortify implementations). Distros are now setting the fortify cflags as default for their toolchain packages, and it would be good usability if users do not need to disable fortify to enable sanitizers.

[MaskRay]

LGTM to me as well, but I wonder how hard would to make sanitizer work properly with forfity calls (maybe just bypass them to internal fortify implementations). Distros are now setting the fortify cflags as default for their toolchain packages, and it would be good usability if users do not need to disable fortify to enable sanitizers.

Thanks for the comment. To work with fortify calls in an uninstrumented prebuilt DSO, interceptors would be needed.
To work with forced -D_FORTIFY_SOURCE=[2|3], perhaps in some cases instead of more interceptors, the C library headers or __builtin_* function implementation can do something.

In any case, there is substantial exploration area that the release/19.x releases will be ready for. We can disable this test first.