<div dir="ltr">Oh ok. <div>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!</div><div><br><br><br><br>On Monday, July 10, 2017 at 1:09:43 PM UTC+2, Dmitry Vyukov wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Jul 10, 2017 at 1:06 PM, Nischai Vinesh

<br><<a href="javascript:" target="_blank" gdf-obfuscated-mailto="ElYjhU0uBAAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">nischai...@gmail.com</a>> wrote:

<br>> I think the code is not getting instrumented with tsan at all. In the 'step

<br>> 3', when I instrument it using 'opt -tsan ...', it gives a warning "WARNING:

<br>> You're attempting to print out a bitcode file." I guess this method doesn't

> instrument the code.

<br>>

> Is there any other way I can instrument the code with tsan?

<br>

<br>

One option is to add your pass to llvm and execute clang with -fsanitize=thread.

<br>

<br>

<br>> On Monday, July 10, 2017 at 7:21:28 AM UTC+2, Dmitry Vyukov wrote:

<br>>>

<br>>> On Sun, Jul 9, 2017 at 3:50 PM, Nischai Vinesh <<a>nischai...@gmail.com</a>>

<br>>> wrote:

<br>>> > Hello,

<br>>> >

<br>>> > I tried that as well but there are no tsan warnings thrown at run time,

<br>>> > even

>> > though there are data race error!

<br>>> >

<br>>> > The steps I followed:

<br>>> > 1. Generate bitcode using 'clang -emit-llvm' command

<br>>> > 2. Using the 'opt -load ..' command, I instrumented the bitcode file

<br>>> > with my

<br>>> > custom pass

<br>>> > 3. Using the command 'opt -tsan ..', instrumented the output bitcode

<br>>> > file

<br>>> > from step 2

<br>>> > 4. Using the llvm backend compiler, 'llc', compiled the program to

<br>>> > native

<br>>> > assembly

<br>>> > 5. The output from step 4 is compiled again with 'clang

<br>>> > -fsanitize=thread'

>> > (linking tsan here) for the final object file.

<br>>> >

<br>>> > Executing this final output file works fine, except that it doesn't

<br>>> > throws

<br>>> > any TSAN warnings!

<br>>>

<br>>>

<br>>> Hi Nischai,

<br>>>

<br>>> I see 3 possibilities:

<br>>> 1. Either the code is somehow ends up being non-instrumented, or

<br>>> 2. tsan does not consider what it sees a data race, or

>> 3. the data race is masked by unrelated synchronization.

<br>>>

<br>>> For 1 you can check that the resulting code in fact contains __tsan_*

<br>>> callbacks.

<br>>> For 2 and 3 you can rebuilt tsan runtime with TSAN_DEBUG_OUTPUT=2

<br>>> define, then it will print everything it sees (memory accesses and

<br>>> synchronization). This output will allow us to figure out why it does

>> not report a race.

<br>>

<br>> --

<br>> You received this message because you are subscribed to the Google Groups

<br>> "thread-sanitizer" group.

<br>> To unsubscribe from this group and stop receiving emails from it, send an

> email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="ElYjhU0uBAAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">thread-sanitiz...@googlegroups.com</a>.

> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout</a>.

<br></blockquote></div></div>