[PATCH] D28836: [tsan] Provide API for libraries for race detection on custom objects

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

kubamracek added a comment.

> Please elaborate here. I need to understand the use case.
> 
>> void  __tsan_external_read(void *addr, void *caller_pc, void *tag);
>>  void  __tsan_external_write(void *addr, void *caller_pc, void *tag);
> 
> Are they meant to be called from instrumented code or from non-instrumented code?

>From non-instrumented code.  We want to bake the callbacks to `__tsan_external_*` into regular (shipped) builds of some system libraries, framework and API suppliers.  We can't ship those libraries TSanified (performance, security) nor can we maintain interceptors for them (too many APIs, changing APIs, ...).  At this point, it's not clear which libraries will adopt this, but the idea is that any library that provides "objects" via opaque handles should be able to use these callbacks to detect races on the API-user side.

E.g. libcurl's `curl_easy_init` returns a `CURL *` handle, which you can only use to call other libcurl functions.  You can pass the handle to a different thread, but you must only use the handle from one thread at a time (this is stated in the API docs).  Even if there is no real race happening, using the same handle to call libcurl methods in two threads without synchronization is a bug -- we want to detect those.  Now, I don't think libcurl should actually adopt these callbacks, but there are other libraries shipped in macOS which are very good candidates for this, because 1) they're frequently used in multithreaded ways, 2) users often misuse them, 3) we're the developers of them.

> We should not assume nor impose the two-level hierarchy of library/object_type... Just one string for object identification is enough.
>  It covers all of "MyLibrary::Archiver", "another_library.foo/bar", "fd", "stdout".

Right.  I agree.


Repository:
  rL LLVM

https://reviews.llvm.org/D28836