<div dir="ltr">Sure. In this case, IMO it makes more sense to relax the expected output rather than XFAIL the test.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 29, 2016 at 11:03 AM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Feb 29, 2016 at 8:00 PM, Alexey Samsonov <<a href="mailto:vonosmas@gmail.com">vonosmas@gmail.com</a>> wrote:<br>
> On Mon, Feb 29, 2016 at 5:09 AM, sagar <<a href="mailto:sagar.thakur@imgtec.com">sagar.thakur@imgtec.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> The stack trace produced by TSan is:<br>
>><br>
>>   Previous write of size 8 at 0x0120ed2930 by thread T1:<br>
>>     #0 memset<br>
>> /home/slt/LLVM/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:678<br>
>> (race_on_mutex.c.tmp+0x0120071808)<br>
>>     #1 __GI___pthread_mutex_init<br>
>> /build/glibc-g99ldr/glibc-2.19/nptl/pthread_mutex_init.c:84<br>
>> (libpthread.so.0+0x000000d634)<br>
>>     #2 <null><br>
>> /home/slt/LLVM/llvm/projects/compiler-rt/test/tsan/race_on_mutex.c:11<br>
>> (race_on_mutex.c.tmp+0x01200ea59c)<br>
>><br>
>> The actual cause may be that the memset call at pthread_mutex_init.c:84 is<br>
>> not in-lined for mips where as it is in-lined for x86 targets.<br>
>> Should we adjust the expected output?<br>
><br>
><br>
> So, do I understand correctly that on MIPS we do call pthread_mutex_init()<br>
> interceptor, which then calls real pthread_mutext_init() from libpthread.so,<br>
> which calls memset(), and TSan records this memset as "memory write",<br>
> instead of explicit "MemoryWrite()" from MutexCreate()?<br>
><br>
> If that's the case, then we can consider fixing the interceptor code<br>
> instead. Generally, in sanitizers we annotate that a certain memory region<br>
> will be<br>
> accessed by the actual libc/libpthread function before we call this actual<br>
> function. Maybe, we can follow the same approach here, and call<br>
> MemoryWrite()<br>
> on mutex from mutex-related interceptors before we're calling the "real"<br>
> function. Dmitry, WDYT?<br>
<br>
</div></div>Tsan does not guarantee that the report will include the oldest/newest<br>
memory access. It's more-or-less random.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div></div>
</div>