[llvm-dev] Using TSAN along with custom llvm IR pass

[Dmitry Vyukov via llvm-dev]

I don't know.

On Mon, Jul 10, 2017 at 3:00 PM, Nischai Vinesh
<nischai.vinesh at gmail.com> wrote:
> Oh ok.
> But is there any dependency when I change to this method, other than the way
> the pass is registered? Because when I used clang along with -Xclang to run
> the pass on the program, it is crashing!
>
>
>
>
> On Monday, July 10, 2017 at 1:09:43 PM UTC+2, Dmitry Vyukov wrote:
>>
>> On Mon, Jul 10, 2017 at 1:06 PM, Nischai Vinesh
>> <nischai... at gmail.com> wrote:
>> > 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?
>>
>>
>> One option is to add your pass to llvm and execute clang with
>> -fsanitize=thread.
>>
>>
>> > On Monday, July 10, 2017 at 7:21:28 AM UTC+2, Dmitry Vyukov wrote:
>> >>
>> >> On Sun, Jul 9, 2017 at 3:50 PM, Nischai Vinesh <nischai... 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 bitcode file
>> >> > with my
>> >> > custom pass
>> >> > 3. Using the command 'opt -tsan ..', instrumented the output bitcode
>> >> > file
>> >> > from step 2
>> >> > 4. Using the llvm backend compiler, 'llc', compiled the program to
>> >> > native
>> >> > assembly
>> >> > 5. The output from step 4 is compiled again with 'clang
>> >> > -fsanitize=thread'
>> >> > (linking tsan here) for the final object file.
>> >> >
>> >> > Executing this final output file works fine, except that it doesn't
>> >> > throws
>> >> > any TSAN warnings!
>> >>
>> >>
>> >> Hi Nischai,
>> >>
>> >> I see 3 possibilities:
>> >> 1. Either the code is somehow ends up being non-instrumented, or
>> >> 2. tsan does not consider what it sees a data race, or
>> >> 3. the data race is masked by unrelated synchronization.
>> >>
>> >> For 1 you can check that the resulting code in fact contains __tsan_*
>> >> callbacks.
>> >> For 2 and 3 you can rebuilt tsan runtime with TSAN_DEBUG_OUTPUT=2
>> >> define, then it will print everything it sees (memory accesses and
>> >> synchronization). This output will allow us to figure out why it does
>> >> not report a race.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "thread-sanitizer" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to thread-sanitiz... at googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "thread-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to thread-sanitizer+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.