[PATCH] D16191: [tsan] Add TSan debugger APIs

Kuba Brecka via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 15 01:15:29 PST 2016


kubabrecka added a comment.

> What do you want to achieve?

>  __tsan::OnReport already exposes ReportDesc. And it is enough to do the checks.


Exposing ReportDesc is hard, because its definition requires a lot of header files, the structure is complex, and it's not stable.  I want the user to be able to use this API in a binary distribution of Clang, where we don't have TSan internal headers.  I want to provide API so the user can do something like:

  __tsan_on_report(void *report) {
    void *addr = ...; // retrieve the address on which a race was detected
    my_logging(..., addr); // do whatever I want with the report data
  }
  int main() {
    ... the program I'm testing with TSan ...
  }

> Long time ago we had lots of tests that did exactly this:

> 

>   assert(tid == 0);

>   assert(addr == &my_global);

>   assert(size == 8);

>   assert(write == 1);

>   assert(atomic == 0);

>   assert(trace[0] > (void *)&main);

>   assert(trace[0] < (void *)&__tsan_on_report);

>   assert(trace[1] == 0);

> 

> They proved to be very painful to write and to maintain. And in the end they don't actually verify what uses sees (e..g all checks can pass but we print nothing at all). I've dropped them in favor of output_tests. I've spent half an hour trying to find them, but unfortunately it seems that we've dropped our history and masked it with file copies without using svn cp.


Are you against asserts or against the API?  If the first, I can print all the stuff in the test and verify it with `// CHECK:`.


http://reviews.llvm.org/D16191





More information about the llvm-commits mailing list