[compiler-rt] [compiler-rt][rtsan] ptrace interception on Linux. (PR #123941)

[via llvm-commits]

================
@@ -1319,6 +1323,39 @@ INTERCEPTOR(ssize_t, process_vm_writev, pid_t pid,
 #define RTSAN_MAYBE_INTERCEPT_PROCESS_VM_WRITEV
 #endif
 
+#if SANITIZER_INTERCEPT_PTRACE
+#if SANITIZER_MUSL
+INTERCEPTOR(long, ptrace, int request, ...) {
+#else
+INTERCEPTOR(long, ptrace, enum __ptrace_request request, ...) {
+#endif // SANITIZER_MUSL
+  __rtsan_notify_intercepted_call("ptrace");
+  va_list args;
+
+  // A handful of ptrace requests need an additional argument on Linux/sparc
+  // (e.g. PTRACE_READDATA) but we only intercept the standard calls at the
+  // moment. We might need to rework all if rtsan is supported on BSD,
+  // interfaces differ vastly, data is read in word size on Linux vs large
+  // chunks on freebsd and so on ...
+  va_start(args, request);
+  pid_t pid = va_arg(args, pid_t);
----------------
davidtrevelyan wrote:

I don't feel like I have enough knowledge about the common usage of `prctl` and `ptrace` to be able to provide meaningful insight here. @devnexen - what was the main motivation for introducing these interceptors from your perspective? In your experience, are these functions often called directly by developers? Is there a common route to them through some standard library tooling?

https://github.com/llvm/llvm-project/pull/123941