fmayer wrote: > > > With the function effects warnings (as errors) activated, blocking > > > functions cannot be called from non-blocking functions, and this is > > > enforced at compile time. The purpose of this series of PRs is to > > > introduce similar functionality into RealtimeSanitizer, so that it can > > > make the equivalent check at run time. > > > > > > What is the reason we need to check something again at runtime that was > > already checked at compile-time? In case people didn't `-Werror` the > > warning? > > Yes indeed - that's one of a few scenarios where we believe this is needed: > > * the user didn't compile with `-Werror`, > * the user didn't compile with `-Wfunction-effects` (i.e. no checking at > compile time happens), > * the `[[clang::blocking]]` function is called deep within the call stack of > a higher-level `[[clang::nonblocking]]` function, or maybe even > * the `[[clang::blocking]]` function is pre-compiled in a different library > to what the user is compiling. > > RTSan differs from the performance constraints attributes in that it only > flags violations that happen at run time, in contrast to flagging those that > _could_ happen at compile time. In this scenario, if a `[[clang::blocking]]` > call exists somewhere in the code within a `[[clang::nonblocking]]` function, > rtsan does not consider it a violation until it's called. Depending on the > user's needs they may consider this either good or bad - there are pros and > cons to it, of course. RTSan takes an "innocent until proven guilty" > approach, whereas performance constraints are more pessimistically "guilty > until proven innocent" - and we think both are very useful. > > One of the design goals of the works was that these systems should be able to > be used easily together, or separately, and that they should have analogous > functionalities where possible. Hope that makes some sense!
Thanks for confirming. Optionally mention this somewhere in a comment in the code for future reference. https://github.com/llvm/llvm-project/pull/111055 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
