[LLVMdev] "anchor" method policy, request for clarification

Patrik Hägglund H patrik.h.hagglund at ericsson.com
Wed Jun 12 13:44:59 PDT 2013


I tried to build LLVM with 'gcc-4.8.1 -flto', and when linking unittest programs, I got the following error:

/tmp/cc8pMk84.ltrans30.ltrans.o:(.data.rel.ro._ZTIN4llvm2cl15OptionValueCopyISsEE[_ZTIN4llvm2cl15OptionValueCopyISsEE]+0x10): undefined reference to `typeinfo for llvm::cl::GenericOptionValue'
/tmp/cc8pMk84.ltrans30.ltrans.o:(.data.rel.ro._ZTIN4llvm2cl15OptionValueCopyINS0_13boolOrDefaultEEE[_ZTIN4llvm2cl15OptionValueCopyINS0_13boolOrDefaultEEE]+0x10): undefined reference to `typeinfo for llvm::cl::GenericOptionValue'

This seems to be due to the (mis-)use of "anchor" methods in CommandLine. I commited r183830, with a removal of the anchor method for GenericOptionValue, which solved my link problem. Also, the commit didn't change the number of vtables, as measured by:

find -name \*.o | xargs nm -C | grep 'V vtable' | grep OptionValue | wc


The current LLVM developer policy text regarding "anchor" methods is:

"If a class is defined in a header file and has a vtable (either it has virtual methods or it derives from classes with virtual methods), it must always have at least one out-of-line virtual method in the class. Without this, the compiler will copy the vtable and RTTI into every .o file that #includes the header, bloating .o file sizes and increasing link times."

I don't know much about when vtable copies are generated, and I guess it may vary slightly between implementations. However, according to my gut feeling, this is an insufficient description.

First, using only #include (only defining the class) seems insufficient to generate a copy of the vtable. I thought  that a class instantiation (creating a class object) was necessary. Specifically, in my case above, having an anchor method for an abstract class seems wrong, because abstract classes are never instantiated. The policy text needs a more detailed description, telling when an (unwanted) vtable is generated.

(Secondly, how to enforce this rule for class templates. Should the anchor method be defined at each template instantiation? This seems like, for a single anchor declaration in a header file, quite a lot of anchor method definitions may be necessary, over many different translation units.)

/Patrik Hägglund

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130612/74eac870/attachment.html>


More information about the llvm-dev mailing list