RE: [PING] [PATCH] Fix parameters of __tsan_vptr_update

[Bernd Edlinger <bernd dot edlinger at hotmail dot de>]

Hi,

On Tue, 20 Jan 2015 17:47:29, Konstantin Serebryany wrote:
>>
>> We discussed two alternatives to sleep:
>>
>> 1. step function, optionally with sched_yield to make it somewhat less busy waiting:
>> __attribute__((no_sanitize_thread))
>> void step (int i)
>> {
>> while (__atomic_load_n (&serial, __ATOMIC_ACQUIRE) != i - 1)
>> sched_yield();
>> __atomic_store_n (&serial, i, __ATOMIC_RELEASE);
>> }
>
> This will not work: tsan will still instrument atomics in a function
> with __attribute__((no_sanitize_thread))
> (This applies to both clang and gcc variants)
>
>> 2. tsan-invisible barriers:
>>
>> cat tsan_barrier.h
>> /* TSAN-invisible barriers. Link with -ldl. */
>> #include <pthread.h>
>> #include <dlfcn.h>
>>
>> static __typeof(pthread_barrier_wait) *barrier_wait;
>>
>> static
>> void barrier_init (pthread_barrier_t *barrier, unsigned count)
>> {
>> void *h = dlopen ("libpthread.so.0", RTLD_LAZY);
>> barrier_wait = (__typeof (pthread_barrier_wait) *)
>> dlsym (h, "pthread_barrier_wait");
>> pthread_barrier_init (barrier, NULL, count);
>> }
>
> So, we will have a single extra header file, but no extra .c files.
> This sounds tolerable.
> I am not sure how portable that is, but today's tsan works only on
> modern Linux anyway.
>
> If you want to contribute the code, please send a patch to upstream LLVM:
> we may not be able to take the code from gcc source tree to LLVM, the
> other direction is easy.
> Or please give us some time to fix the tests in upstream ourselves and
> than port them to the gcc test suite.
>

That's fine, LLVM is out of my reach so I can't do that myself, but I will
always help if I can.

> Dmitry, wdyt?
>
>
>>
>>
>> We preferred the second alternative, because it does not do busy waiting.
>> We include this header file in every positive test case and link with -ldl.
>
> -ldl is not required, since -fsanitize=thread already adds that.
>

Maybe that is a driver issue or just a linker oddity.
Clang will probably use a different linker.

In our case however, if I do not add -ldl to the application,
the linker complains about the missing DSO in the command line.

Also if I use -fsanititze=thread I do in most cases not need -pthread on the
command line, but if I happen to use a non-intercepted pthread function
for instance pthread_yield() I get an error:

cat test.c
#define _GNU_SOURCE
#include <pthread.h>
int main()
{
  pthread_yield();
  return 0;
}

gcc test.c -fsanitize=thread 
/home/ed/gnu/install/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/bin/ld: /tmp/ccGGRrgy.o: undefined reference to symbol 'pthread_yield@@GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

gcc test.c -fsanitize=thread -pthread
=> OK


Bernd.