A straightforward port of tsan to the new PM, following the same path
as D55647.
Details
Diff Detail
- Build Status
Buildable 26485 Build 26484: arc lint + arc unit
Event Timeline
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.
Similar documentation update as for msan?