[PATCH] D54889: Fiber support for thread sanitizer

Yuri Per via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 10 05:11:55 PST 2018


yuri marked an inline comment as done.
yuri added inline comments.


================
Comment at: lib/tsan/rtl/tsan_rtl_thread.cc:115
   // TraceAddEvent will reset stack0/mset0 in the new part for us.
-  TraceAddEvent(thr, thr->fast_state, EventTypeMop, 0);
+  TraceAddEvent(thr, thr->fast_state, EventTypeMop, 0, false);
 
----------------
dvyukov wrote:
> yuri wrote:
> > dvyukov wrote:
> > > I think we should execute start on the fiber itself. This is what we do for normal threads. This should resolve the hacky call problem (right?) and also prevent fibers from breaking in future.
> > > We can do this either by briefly switching to the fiber context and back when we create a new fiber. Or, start it lazily on first switch.
> > Start indeed can be executed on the first call to __tsan_switch_to_fiber(), but this solution is not suitable for destroying fiber, because it is normal for fiber to cycle in infinite loop and be destroyed externally.
> > Do you think it is safe to temporary switch to fiber context for calling ThreadStart and/or ThreadFinish without actually switch to fiber stack?
> Do we use trace in ThreadFinish?
> If not, then it's not a problem. If yes, then switching to the fiber looks fine to me and better then changing non-local code invariants.
> 
> If we do this, do we still need any hacky call changes?
There is no trace in ThreadFinish for detached thread, but it uses proc(), so it is better to switch temporary.
I think, hacky call changed can be reverted. I will check it.


Repository:
  rCRT Compiler Runtime

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54889/new/

https://reviews.llvm.org/D54889





More information about the llvm-commits mailing list