OMPT-annotations

[jprotze]

Can we detect in the initialization of the OMPT-tool, whether the application is built with TSan or not?
If that would be possible, we could avoid to register the callbacks and remove the potential overhead. This would be a good step for pushing Archer upstream in the long run.

[dongahn]

Interesting. One way is to check if the TSan runtime is linked in.

[jprotze]

With clang, the tsan runtime is linked statically. So, I don't know how this might work at runtime.

[simoatze]

The problem is that we could have a program that only has some parts/sources/modules/libraries built with the instrumentation, and some that are not.
So we could check if the program is running with the TSan runtime for example using dlsym("__tsan_read8") or some other well-known exported function.
We could probably iterate over loaded modules and look for "libclang_rt.tsan...".

With tsan we could even have the Tsan runtime running and zero instrumented files and Tsan would still catch problems using the interceptors, but I guess that's not the case for OpenMP programs so one of the previous solution should work.

[jprotze]

dlsym only works if the application is built with -rdynamic (see the earlier mail to Alex).

[simoatze]

Even if you are looking for symbols from other libraries? I thought it was just a problem with the OMPT symbols

[dongahn]

You can use nm or BFD library type (https://en.wikipedia.org/wiki/Binary_File_Descriptor_library) on the executable to check the presence of a well-know symbol. But this would be too heavyweight for this purpose...

A better solution would be for TSan itself leave a mark to program header somewhere for the programming model add-on like ours to check. I think PT_NOTE section seems promising.

https://linux.die.net/man/5/elf

One could prototype this in clang or direct ask Sanitizer folks whether they already have something like this?

[simoatze]

@dongahn why nm or BFD would be heavyweight? It's just a one time check at the OMPT initialization, it shouldn't add that much overhead. I don't think TSan leave any mark in the program header, but I could ask.

[dongahn]

True. But I'm just concerned about having to deal with a large executable. Instead if this is encoded in the program header of the main executable, perhaps we can write a code to only get to the small memory segment...

[jprotze]

The TSan annotation interface has a RunningOnValgrind function. I couldn't find documentation on the semantics of the function. But I think, a similar function RunningOnTSan that returns true would be helpful. By implementing this function weak in the tool returning false, it would be easy to decide whether TSan is there or not.

[dongahn]

@jprotze: yes this would be another good - even a more reliable way to check the presence of TSan.

[simoatze]

we can create such Annotation if missing and if it works we can try to propose it to the LLVM folks

[jprotze]

I think, I found a side-effect solution for this:

we use a weak implementation of RunningOnValgrind, that changes a static variable in our tool. If TSan is there, the provided RunningOnValgrind function would not change this variable.

[simoatze]

@jprotze yes that would totally work.
I am currently doing some bug fixing and changing the Instrumentation pass to work with Clang/LLVM 6.0.
We can add it in the next release , if you have time we can work on it together.

[simoatze]

@jprotze I tried RunningOnValgrind and it does not get called by Tsan.
Take a look to this thread for a possible way to find out if the program is running tsan https://groups.google.com/forum/#!searchin/thread-sanitizer/compiled$20with$20tsan%7Csort:date/thread-sanitizer/xUi2rFUltM0/eW3PdjhYBQAJ

[jprotze]

@simoatze I just pushed my idea of the workflow to the RunningOnValgrind branch.
I think, that the APPLE variants of the annotation functions should somehow detect and avoid endless recursion (by calling the function itself) in the case, that there are no annotation functions in the application.