search for: cur_thread

...t? I don't know what it worth to add __thread support to android, and whether somebody is going to address it soon. But I think we can make the tls emulation _much_ cleaner. First, we need to put all tsan per-thread data into ThreadState object, accesses to ThreadState are already wrapped into cur_thread() function. So now we have a single function to modify, no macros spread across the codebase, no new files, etc. Then, I've looked at pthread_getspecific code in bionic and it is actually quite fast and does not call any other system function (except get_thread() which is basically an access to...

...ed to reproduce this as well, but unsuccessfully. From the crash >> report: EXC_I386_GPFLT means we’re dereferencing a non-canonical pointer, >> in this case “0x00486000000025df”. This happens at wrap_OSSpinLockLock+17, >> which is just after the prologue and just after calling cur_thread(). So >> I’d say it happens when we’re dereferencing the pointer returned by >> cur_thread(). On OS X, we’re doing this trick where we store the >> ThreadState pointer in the shadow memory. Could it be that something >> actually read/wrote the memory that is backed by the...

Hm, I tried to reproduce this as well, but unsuccessfully. From the crash report: EXC_I386_GPFLT means we’re dereferencing a non-canonical pointer, in this case “0x00486000000025df”. This happens at wrap_OSSpinLockLock+17, which is just after the prologue and just after calling cur_thread(). So I’d say it happens when we’re dereferencing the pointer returned by cur_thread(). On OS X, we’re doing this trick where we store the ThreadState pointer in the shadow memory. Could it be that something actually read/wrote the memory that is backed by the same place as the shadow memory? D...

On Tue, Aug 18, 2015 at 8:28 PM, Kostya Serebryany <kcc at google.com> wrote: > +dvyukov > > On Mon, Aug 17, 2015 at 8:37 AM, Renato Golin <renato.golin at linaro.org> > wrote: >> >> Folks, >> >> The review of patch http://reviews.llvm.org/D11532 is extremely slow >> due to the number of hacks, left-overs and general undesired changes >>

...o do TLS emulation are thoroughly > justified. Right now, it's just a hunch. > > >> But I think we can make the tls emulation _much_ cleaner. First, we >> need to put all tsan per-thread data into ThreadState object, accesses >> to ThreadState are already wrapped into cur_thread() function. So now >> we have a single function to modify, no macros spread across the >> codebase, no new files, etc. > > I'm no expert in that field, but this sounds like a good plan. Doesn't > seem to be part of this patch, though. Nor it should, as it actually >...

On 26 August 2015 at 20:13, Jason Kim <jasonk at codeaurora.org> wrote: > I had been discussing the TSAN on android/aarch64 issues with the folks at thread-sanitizer at googlegroups.com for several months now. I had not explicitly been including llvm-dev (and you), and that was a mistake on my part. Palm-on-face? :-( Yup, that would have saved a lot of emails... :) > Patch Size!

Ah ha! I found crash reports: green-dragon-03:DiagnosticReports buildslave$ cat mmap_stress.cc.tmp_2016-01-19-231335_green-dragon-03.crash Process: mmap_stress.cc.tmp [95010] Path: /Users/USER/*/mmap_stress.cc.tmp Identifier: mmap_stress.cc.tmp Version: 0 Code Type: X86-64 (Native) Parent Process: bash [95004] User ID: