[LLVMdev] RTTI Madness

[Chris Lattner]

On Jan 28, 2010, at 12:45 PM, Thomas B. Jablin wrote:

> Hi,
> Lately LLVM has been adding -fno-rtti to most of the compiler. I  
> have a pass which uses LoopPass and which inherits from FunctionPass  
> and a class of my own. If I compile my code with ENABLE_RTTI=1, I  
> can't dynamically load the shared object since it won't be able to  
> find the symbol for LoopPass's typeinfo.
>
> undefined symbol: _ZTIN4llvm8LoopPassE
> $ c++filt _ZTIN4llvm8LoopPassE
> typeinfo for llvm::LoopPass
>
> Alternatively, if I compile with ENABLE_RTTI=1 then the virtual  
> table for my FunctionPass will be messed up. FunctionPass comes from  
> Pass.cpp in ./lib/VMCore which is built with ENABLE_RTTI=1. The  
> difference in the size of the virtual tables between LLVM's code,  
> which is built with RTTI, and my code, which is built without causes  
> the offsets into my derived class's virtual table to be wrong.
>
> What is the recommended course of action?
>
> I don't mind disabling RTTI globally, but I don't understand how  
> RTTI and non-RTTI code can be correctly dynamically linked when  
> there is multiple-inheritance. Unless someone else has a better  
> idea, my preference would be compiling with ENABLE_RTTI=1 globally  
> until the entire compiler is ready to go RTTI-free.
>
> Alternatively, if anyone knows a safe way to dynamically link RTTI  
> and non-RTTI code, I'd appreciate their expertise.

This was really irritating to me as well, when I was trying to to  
eliminate RTTI.  The best advice I can give is that it is best to stop  
using RTTI (and EH) in any of your code if possible.  If you want to  
build LLVM with full rtti support, you can add a REQUIRES_RTTI=1  
setting to the top level Makefile.config or on the make command line.

-Chris