[PATCH] D31553: [tsan] Ignore memory accesses for libignored modules for "external" races

[Kuba (Brecka) Mracek via Phabricator via llvm-commits]

kubamracek added a comment.

In https://reviews.llvm.org/D31553#716166, @dvyukov wrote:

> Wait, the external API was meant specifically to be used from non-instrumented libraries. Quoting you in https://reviews.llvm.org/D28836:
>
> > It might not be feasible/easy to recompile the library with TSan instrumentation... The idea of this patch is to allow a non-instrumented library to call into TSan runtime.
>
> With this change it all become pointless. We annotate non-instrumented libraries and then ignore that. What am I missing?


There's multiple scenarios, but a typical one can be:  An API provider, which is shipped with the OS as a non-instrumented library, e.g. libcurl, adopts the TSan external API.  Now users of libcurl don't need to recompile libcurl to detect when they're violating the libcurl's API threading rules.  Even with the non-instrumented version of libcurl, TSan will report whenever you're using a `CURL *` object from multiple threads without synchronization.  However, if you're using a 3rd party library (or a system library) that is *also non-instrumented* and uses libcurl, let's call it libftp, we would report bugs as well, even though they're not your bugs.  And they could be real bugs (libftp has races) or false positives (libftp uses some atomic-based synchronization that is TSan-invisible), but they're still out of the user's control to fix.  This patch silences reports that come from `instrumented_module -> libftp -> libcurl`, but still reports bugs from `instrumented_module -> libcurl`.

If the user actually wants to see races even in non-instrumented code (typically system libraries and 3rd party binary frameworks), they can always set the flag `ignore_noninstrumented_modules` back to 0.


Repository:
  rL LLVM

https://reviews.llvm.org/D31553