Archer uses weak symbol overloads of TSan functions to enable loading the tool even if the application is not built with TSan. For MACOS the tool collects the function pointer at runtime.
When adding the function entry/exit markers, we missed to add the functions in the MACOS codepath.
This patch also replaces the repeated function lookup by a single initial function lookup.
Details
- Reviewers
Hahnfeld jdoerfert - Commits
- rG82e4e505315b: [OpenMP][Tools] Fix Archer for MACOS
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
openmp/tools/archer/ompt-tsan.cpp | ||
---|---|---|
157–160 | Can you explain this change? Why do we disable TSan if dlsym finds the current function? (RunningOnValgrind resolves to the current function, right?) | |
941 | Can you indent this line? It's the body of the if. As a general comment, maybe wrap the entire macro in do { ... } while (0) so the semicolon doesn't terminate the if body? |
openmp/tools/archer/ompt-tsan.cpp | ||
---|---|---|
157–160 | I never had a chance to test the library on Mac. While preparing this patch, I tested the library on my Linux system by manually enabling the ifdefs for mac. From my understanding the library should never have worked on Mac. Line 1090 sets runOnTsan=1. If any other RunningOnValgrind is found (and executed in the weak function approach), the function will not modify runOnTsan. If no other RunningOnValgrind is found, the function should set runOnTsan=0. In this case, Archer will return NULL from ompt_start_tool and allow other tools to get loaded. I think, the general question is whether it's worth to still have all the symbols in the library or whether we should allow dlopen to fail if the application is not built with TSan? The OpenMP runtime now has OMP_TOOL_VERBOSE_INIT which allows to understand why dlopen failed. |
openmp/tools/archer/ompt-tsan.cpp | ||
---|---|---|
157–160 | From my memory, I think the dynamic linker on macOS always prefers functions in the current image - that's why we have to play the funny dlsym tricks in the first place, right? So if we end up in this function, and fptr == RunningOnValgrind / the current function, we're not running under Valgrind and should not set runOnTsan = 0;. Am I missing something? |
openmp/tools/archer/ompt-tsan.cpp | ||
---|---|---|
157–160 | Tsan implements this function. The goal of the function is not to distinguish between TSan/Valgrind, but rather to see whether a consumer for the DR annotations is available. I could not find valgrind documentation about this function. Probably we completely missed the idea of the function, when we used the function to detect whether TSan is available in the application. As I wrote in my last comment, we could just remove all the fallback implementation of the TSan functions from this library and fail to load the library when the application is not built with TSan. |
Can you explain this change? Why do we disable TSan if dlsym finds the current function? (RunningOnValgrind resolves to the current function, right?)