[compiler-rt] [rtsan] Introduce blocking-fn-name and intercepted-fn-name suppressions (PR #112108)

Chris Apple via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 14 15:38:25 PDT 2024


cjappl wrote:

> High level question: why do we distinguish whether it's intercepted or blocking? Does the user care?

Good question. I think the answer is "yes, the user cares".

A lot of this complexity (why we distinguish between intercepted and blocking) is to show the user a different error message:

For malloc, an intercepted call:
```
==51105==ERROR: RealtimeSanitizer: unsafe-library-call
Intercepted call to real-time unsafe function `malloc` in real-time context!
```

For a user defined [[clang::blocking]] call:
```
==51326==ERROR: RealtimeSanitizer: blocking-call
Call to blocking function `my_special_allocation()` in real-time context!
```

I think this is useful because it indicates whether or not this is directly controllable by code outside of glibc. If I get the second, I will know that some dev on my team, or library, marked this call as [[blocking]], and I should perhaps interrogate that source code to see if I agree with the attribute.

To simplify our code a lot, we **could** move to a unified error message, and treat both issues as the same, something like:
```
==51326==ERROR: RealtimeSanitizer: unsafe-call
Call to non-real-time-safe function `my_special_allocation()` in real-time context!
...
==51326==ERROR: RealtimeSanitizer: unsafe-call
Call to non-real-time-safe function `malloc()` in real-time context!
```

But I think that we might lose some important detail in the process. The user may behave differently based on if it is an intercepted function vs a [[blocking]] function.

We have discussed a bit if we want to have some notification of an unbound loop. While the details of this (or if it is even possible) are outside the scope of this comment, again I think it would be nice to be notified specifically of what went wrong, instead of a general error message:

```
==51326==ERROR: RealtimeSanitizer: unbound-loop
Potentially unbound loop called from real-time context!
```


WDYT?

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


More information about the llvm-commits mailing list