similar to: Using TSAN along with custom llvm IR pass

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:

On Sun, Jul 9, 2017 at 3:50 PM, Nischai Vinesh <nischai.vinesh at gmail.com> wrote: > Hello, > > I tried that as well but there are no tsan warnings thrown at run time, even > though there are data race error! > > The steps I followed: > 1. Generate bitcode using 'clang -emit-llvm' command > 2. Using the 'opt -load ..' command, I instrumented 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,

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

> 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

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

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 Thu, Jan 3, 2019 at 11:54 PM Kuba Mracek <mracek at apple.com> wrote: > > > > > On Jan 3, 2019, at 1:21 PM, David Greene via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > >> What you're seeing is just the fact that lit is waiting on > >>

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

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,

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

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

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$

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

+thread-sanitizer mailing list On Mon, Sep 7, 2015 at 6:41 PM, Vaivaswatha Nagaraj <vn at compilertree.com> wrote: > Hi, > > I am interested in understand the compiler-rt thread sanitizer tool and have > recently started experimenting with it. In particular, I'm interested in the > deadlock detector. > > I see that deadlock detection currently don't work. (I

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 Thu, Jun 21, 2012 at 1:44 PM, Chandler Carruth <chandlerc at google.com>wrote: > Can we alter the build system so that when building a run-time library it >>>>>>>> modifies all .cpp files like this: >>>>>>>> namespace FOO { >>>>>>>> <file body> >>>>>>>> }

On Thu, Jun 21, 2012 at 11:52 AM, Chandler Carruth <chandlerc at google.com>wrote: > > Hi, >> >> Yes, stlport was a pain to deploy and maintain + it calls normal operator >> new/delete (there is no way to put them into a separate namespace). >> > > Ok, but putting the raw symbols into a "namespace" with the linker > shouldn't be subject to