similar to: TSAN hack on AArch64 for Android

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 >>

On 28 August 2015 at 18:02, Jason Kim <jasonk at codeaurora.org> wrote: > IMO having to disable 2/3 of the tests means the patch isn't ready yet. Dan is absolutely right. > (*) The tests weren’t all stable to begin with. That's not a reason to break them more. If you can't prove they're correct, you can't prove you broken them more, especially on other arches.

Wait, this change is not submitted yet, right? Or you mean mailing of this change in bad shape? I consider this change as work-in-progress where author is looking for feedback on his ongoing progress. I guess the change description should have been spelled this very explicitly. This change definitely needs more work to be submitted, splitting into smaller patches with a plan for submission order,

On Wed, Aug 19, 2015 at 1:15 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 19 August 2015 at 11:29, Dmitry Vyukov <dvyukov at google.com> wrote: >> Wait, this change is not submitted yet, right? Or you mean mailing of >> this change in bad shape? > > Right. > > Jason has submitted high quality patches before, so this is in no way > a reprimand

On Tue, Aug 18, 2015 at 10:53 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 18 August 2015 at 19:57, Dmitry Vyukov <dvyukov at google.com> wrote: >> Hi Renato, >> >> What exactly hack/hacks do you mean? > > Hi Dmitry, > > The sanitizer code seems to be more accepting to adding complicated > pre-processor logic, as well as a number of

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!

IMO having to disable 2/3 of the tests means the patch isn't ready yet. On Fri, Aug 28, 2015 at 9:31 AM, Jason Kim <jasonk at codeaurora.org> wrote: > > > > -----Original Message----- > > From: Renato Golin [mailto:renato.golin at linaro.org] > > > TESTS! > > > Currently, about 2/3 tests for tsan fail/flake on android+aarch64. > > >

Hi everyone. Thanks to everyone for taking the time to meet yesterday. I think it was very productive! I am writing to keep a "minutes" of the meet, as I remember them. Action Items: - Jasonk: split up bionic patch to explicitly replace CPP macros with actual calls, one file at a time. - Google/Android: pthread_barrier interface in bionic - *Enh*: 1 paragraph to explain

> On 2 Sep 2016, at 12:11, Dmitry Vyukov <dvyukov at google.com> wrote: > > On Fri, Sep 2, 2016 at 12:09 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> >>> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com>

Hello, I trying TSAN on Darwin on LLVM itself (sanitizing multi-threaded ThinLTO link). However I see two main issues on my debug build: 1) Statistics: the pre/post increment is not safe, it seems to be acknowledge in the code itself: // FIXME: This function and all those that follow carefully use an // atomic operation to update the value safely in the presence of // concurrent

On Tue, Jun 27, 2017 at 4:18 PM, Nischai Vinesh <nischai.vinesh at gmail.com> wrote: > Hello, > > I have written a custom pass to do some tasks and I want to run this pass on > a source code file along with TSAN instrumentation. > > Steps I followed: > 1. I compiled the code file with -fsanitize=thread and -emit-llvm to get the > byte code of the file > 2. Used

On Tue, Nov 28, 2017 at 12:16 AM, Kostya Serebryany <kcc at google.com> wrote: > +dvyukov > > On Mon, Nov 27, 2017 at 4:56 AM, Csaba Raduly via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> I'm trying to build clang on Ubuntu 17.10 - the build succeeds, but >> testing fails: >> >> ~/wk/LLVM/build_release$

> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> Hi, >> >> I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in

I guess there is lots of stuff that you don't care about besides tsan/go that is built and tested during llvm build, and there is no way to selectively disable each one of that. By design. In the long run we need to fix all failures (please file a proper bug). If you are looking for a temporal workaround, then comment it out. I don't what else to suggest. On Tue, Nov 28, 2017 at 9:47 AM,

Hi all, I'm trying to build clang on Ubuntu 17.10 - the build succeeds, but testing fails: ~/wk/LLVM/build_release$ svn info ../llvm/ Path: /home/csabaraduly/wk/LLVM/llvm Working Copy Root Path: /home/csabaraduly/wk/LLVM/llvm URL: https://llvm.org/svn/llvm-project/llvm/trunk Relative URL: ^/llvm/trunk Repository Root: https://llvm.org/svn/llvm-project Repository UUID:

Hi, I consider reducing the usage of blacklist in sanitizer instrumentation passes and doing the necessary work in frontend (Clang) instead. Some of it is already implemented: e.g. Clang will attach an attribute "sanitize_address" to function definition only if this function is not blacklisted. In this case we won't instrument the memory accesses in this function in ASan

Same problem exists, thread A can still be within REAL(call_once), but after it ran user code and set the flag to ~0. Roughly, call_once does: __call_once(flag, arg, func) { mutex_lock(mut); if (flag == BEING_INITIALIZED) { wait } else if (flag == NOT_INITIALIZED_AT_ALL) { flag = BEING_INITIALIZED; mutex_unlock(mut); func(arg); // <=== user code callback

On Tue, Jun 27, 2017 at 6:00 PM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Tue, Jun 27, 2017 at 4:18 PM, Nischai Vinesh > <nischai.vinesh at gmail.com> wrote: >> Hello, >> >> I have written a custom pass to do some tasks and I want to run this pass on >> a source code file along with TSAN instrumentation. >> >> Steps I followed:

Hi, I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. TSan already supports pthread_once and dispatch_once by having interceptors that re-implement the

I think the code is not getting instrumented with tsan at all. In the 'step 3', when I instrument it using 'opt -tsan ...', it gives a warning "WARNING: You're attempting to print out a bitcode file." I guess this method doesn't instrument the code. Is there any other way I can instrument the code with tsan? On Monday, July 10, 2017 at 7:21:28 AM UTC+2,