[rtsan] Fix issue when intercepted function was not execve in test

[cjappl]

On my mac, this started having os_unfair_lock_lock as the intercepted function.

I dropped the name so any second intercepted call will pass the test.

[llvmbot]

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

Author: Chris Apple (cjappl)

Changes

On my mac, this started having os_unfair_lock_lock as the intercepted function.

I dropped the name so any second intercepted call will pass the test.

---

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

1 Files Affected:

• (modified) compiler-rt/test/rtsan/fork_exec.cpp (+6-1)

diff --git a/compiler-rt/test/rtsan/fork_exec.cpp b/compiler-rt/test/rtsan/fork_exec.cpp
index 3b2d2e5ca2f5d..5890a0936a2f7 100644
--- a/compiler-rt/test/rtsan/fork_exec.cpp
+++ b/compiler-rt/test/rtsan/fork_exec.cpp
@@ -45,7 +45,12 @@ int main() MAYBE_NONBLOCKING {
 }
 
 // CHECK-NOHALT: Intercepted call to {{.*}} `fork` {{.*}}
-// CHECK-NOHALT: Intercepted call to {{.*}} `execve` {{.*}}
+
+// We should also get some other intercepted call. On some systems this
+// is `execve`, on others, it's a lock to set up `execve`. In either
+// case, just check that we get a second intercepted call, don't sweat
+// the name.
+// CHECK-NOHALT: Intercepted call to {{.*}}
 
 // usleep checks that rtsan is still enabled in the parent process
 // See note in our interceptors file for why we don't look for `wait`