This is an archive of the discontinued LLVM Phabricator instance.

[TSan] Handle FreeBSD specific indirection of libpthread functions
ClosedPublic

Authored by dim on Feb 4 2022, 12:56 PM.

Details

Summary

Similar to 60cc1d3218fc for NetBSD, add aliases and interceptors for the
following pthread related functions:

  • pthread_cond_init(3)
  • pthread_cond_destroy(3)
  • pthread_cond_signal(3)
  • pthread_cond_broadcast(3)
  • pthread_cond_wait(3)
  • pthread_mutex_init(3)
  • pthread_mutex_destroy(3)
  • pthread_mutex_lock(3)
  • pthread_mutex_trylock(3)
  • pthread_mutex_unlock(3)
  • pthread_rwlock_init(3)
  • pthread_rwlock_destroy(3)
  • pthread_rwlock_rdlock(3)
  • pthread_rwlock_tryrdlock(3)
  • pthread_rwlock_wrlock(3)
  • pthread_rwlock_trywrlock(3)
  • pthread_rwlock_unlock(3)
  • pthread_once(3)
  • pthread_sigmask(3)

In FreeBSD's libc, a number of internal aliases of the pthread functions
are invoked, typically with an additional prefixed underscore, e.g.
_pthread_cond_init() and so on.

ThreadSanitizer needs to intercept these aliases too, otherwise some
false positive reports about data races might be produced.

Diff Detail

Event Timeline

dim created this revision.Feb 4 2022, 12:56 PM
dim requested review of this revision.Feb 4 2022, 12:56 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 4 2022, 12:56 PM
dvyukov added inline comments.Feb 4 2022, 11:27 PM
compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp
297–298

I think it's better to do these netbsd/freebsd-specific macros as:

#if SANIFIZER_SOMEBSD
#  define ... real definition...
#else
#  define ... empty definition
#endif

I see how the current #elif-based structure makes sense for TSAN_INTERCEPT_VER, but it leads to duplication and easy to get wrong for macros that make sense for only 1 OS.

dim updated this revision to Diff 406184.Feb 5 2022, 7:36 AM

Address review comments.

dvyukov accepted this revision.Feb 7 2022, 12:38 AM
This revision is now accepted and ready to land.Feb 7 2022, 12:38 AM