[LLVMdev] RTTI Madness

Jeffrey Yasskin jyasskin at google.com
Thu Jan 28 14:31:24 PST 2010


On Thu, Jan 28, 2010 at 2:16 PM, Török Edwin <edwintorok at gmail.com> wrote:
> 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.

LLVM now builds tests with -DGTEST_HAS_RTTI=0 -DGTEST_HAS_TR1_TUPLE=0
to avoid this problem. Upgrading to googletest 1.4 would avoid the
need for the second option on early gccs but not the first.




More information about the llvm-dev mailing list