A straightforward port of tsan to the new PM, following the same path
as D55647.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Only one real question... Worried a little about the total cost here, but the code looks fine.
llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp | ||
---|---|---|
88 ↗ | (On Diff #180641) | Similar documentation update as for msan? |
179 ↗ | (On Diff #180641) | There are a lot of functions here, including numerous loops... Is this really ok to do every function? |
On further thought, what is maybe best is to land this and see how it goes. LGTM overall. We can try again if something blows up.
@philip.pfaffe This patch got reverted (not by me r350719) because it broke TSan on macOS.
If I diff the LLVM IR between a working AppleClang and the important thing I see is
@.str = private unnamed_addr constant [7 x i8] c"hello\0A\00", align 1 -@llvm.global_ctors = appending global [1 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 0, void ()* @tsan.module_ctor, i8* null }] +@llvm.global_ctors = appending global [1 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 0, void ()* @__tsan_init, i8* null }] ; Function Attrs: noinline norecurse optnone sanitize_thread ssp uwtable define i32 @main() #0 personality i32 (...)* @__gcc_personality_v0 { @@ -30,11 +30,6 @@ declare void @__tsan_init() -define internal void @tsan.module_ctor() { - call void @__tsan_init() - ret void -} -
On macOS it seems dyld doesn't like __tsan_init being called directly from llvm.global_ctors. I get
dyld: initializer function 0x100129cd0 not in mapped image for <path_to_binary>
__tsan_init is external to generated TSan code (it lives in the TSan runtime), where as tsan.module_ctor() was in the same module. Perhaps dyld doesn't like calling functions external to the module directly.
__tsan_init is external to generated TSan code (it lives in the TSan runtime), where as tsan.module_ctor() was in the same module. Perhaps dyld doesn't like calling functions external to the module directly.
I've confirmed this with the authors of dyld. The indirection via tsan.module_ctor() is necessary for Darwin platforms because dyld requires that the global constructors for an image (module) point to functions in the same .TEXT segment as that image.