This patch adds anchor() for MemoryBuffer, raw_fd_ostream, RTDyldMemoryManager, SectionMemoryManager, etc.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
When I statically linking a project (built with RTTI) against LLVM OrcJIT (default built with no-RTTI), I got a couple of "undefined reference to type info" error.
Looks similar to http://lists.llvm.org/pipermail/llvm-dev/2016-February/095671.html
However, I'm not sure where to put the definition of anchor() for ObjectMemoryBuffer class. It's used by ThinLTOCodeGenerator.cpp and MCJIT.cpp, which belong to different libs.
Looks like ObjectMemoryBuffer is part of ExecutionEngine, so having libLTO
dependent on ExecutionEngine seems basically correct for the dependencies
that are there already. Whether or not those dependencies should be there
is another question, I guess. (maybe ObjectMemoryBuffer should be moved
somewhere more common, etc - but I wouldn't worry about doing that unless
the LTO dependency breaks things)
If I choose to define ObjectMemoryBuffer::anchor() in MCJIT.cpp (the module that uses ObjectMemoryBuffer), then I got error like:
../../lib/libLLVMLTO.a(ThinLTOCodeGenerator.cpp.o): In function `ObjectMemoryBuffer':
llvm/ExecutionEngine/ObjectMemoryBuffer.h:41: undefined reference to `vtable for llvm::ObjectMemoryBuffer'
You'd have to add the ExecutionEngine library as a dependency from the LTO
library - by modifying lib/LTO/LLVMBuild.txt - then it should link, I would
think.
Is it sufficient to put the dependency MCJIT in lib/LTO/LLVMBuild.txt (since that's where the dependency on is) & not in the tools that /use/ the LTO lib (I expect they should pickup the indirect dependency implicitly?)?
I put a dependency on tools/llvm-lto as well. From my build (default CMake config), it works.
I meant what happens if you remove the changes to tools/lto/LLVMBuild.txt
and tools/llvm-lto/LLVMBuild.txt and /only/ have a change to
lib/LTO/LLVMBuild.txt - is that sufficient to make the build work?
I tried before and it didn't work. I think it's because lib/LTO is for the generation of libLLVMLTO.a (at least for the default build config), so the dependency on MCJIT has no effect on the archive generation.
That sort of surprises me - if that were the case, there would be no point
having LLVMBuild.txt files in any libraries, I would think?
Hi David,
Do you mean changes like:
diff --git a/lib/LTO/CMakeLists.txt b/lib/LTO/CMakeLists.txt
- a/lib/LTO/CMakeLists.txt
+++ b/lib/LTO/CMakeLists.txt
@@ -13,4 +13,5 @@ add_llvm_library(LLVMLTO
DEPENDS intrinsics_gen llvm_vcsrevision_h
+ LLVMLTO
)
In this case, I think the dependency rule won't affect the build of libLLVMLTO.a. I tried and it didn't work. Or maybe I misunderstood what you meant?
I meant that lib/LTO/LLVMBuild.txt should include "ExecutionEngine" in its
required_libraries. I wouldn't expect any changes would be needed to
tools/lto/* or tools/llvm-lto/*.
Great - thanks for sticking with it, sorry for my dodgy explanations!
If you're adding in anchors, are you using -Wweak-vtables to find them? If you're pushing through to make LLVM (& hopefully Clang/other LLVM subprojects) -Wweak-vtables clean, perhaps you can turn on the warning in the CMake config once it's clean so we don't regress this again? (it'd also be interesting to do some kind of analysis to see whether avoiding weak vtables is /actually/ worthwhile - like maybe making a temporary/local/non-committed change to change all the explicit anchors into inline functions (unanchoring them) & see if builds are much larger or longer, etc)
I got linker error when my code tries to statically link against some LLVM libs (like libLLVMOrc). It's a good idea to turn on -Wweak-vtables to check if we miss other cases. I will try it. Thanks