[compiler-rt] r267864 - [tsan] Fix Darwin GCD support after separation of Processor and ThreadState

[Kuba Brecka via llvm-commits]

>> 
>> Any signal that arrives between cur_thread() and ProcWire will be
>> delayed, right?
>> 
>> 
>> I think signals are actually not disabled during early new thread state, and
>> this bug was already present before this patch :(
> 
> Signals are delayed by default

Ah, you mean delayed by TSan, not delayed by the system.

> , unless we receive a synchronous signal
> or in a blocking function.
> Signal handler still needs to look at ThreadState (that's why we have
> cur_thread async-signal-safe), but it should not touch
> cur_thread->proc1.

Yes, that sounds right.

I think there is still a remaining bug on OS X, when if a signal is delivered very soon in a new thread, cur_thread() is not available, because pthread_self() doesn’t work.  That early, the %gs segment is invalid and reading from TSD (which is where the thread identity is stored) thus doesn’t work.

Just wondering, is there a way to just make sure the system doesn’t deliver signal to that particular thread, until we enable it at a safe point?

Kuba

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160502/ff95e12d/attachment.html>