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

[Florian Mayer via llvm-commits]

fmayer 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?

Right, I meant more in the context of this CL though. If I add a list the ignore list, why do I care if it's blocking or intercepted? I understand it might be useful to note why a function is considered "rt unsafe" in the error mesage.

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