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. Thanks. Tom Jablin
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
On 01/29/2010 12:11 AM, Chris Lattner wrote:> 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. >On a related note, building googletest with gcc-4.4 doesn't require RTTI, while building it with gcc-4.2 does require RTTI (due to tr1/functional using typeid). I'd be happy if there was a solution for that. Best regards, --Edwin