[LLVMdev] RTTI handling

John McCall rjmccall at apple.com
Fri Sep 30 15:24:33 PDT 2011

On Sep 30, 2011, at 3:04 PM, Somorjai, Akos wrote:
> Thanks! Yes, we are trying to avoid that situation as much as possible.
> Is there any compiler/linker/static analyzer option that would point out those problems (in 13 million lines, large part of that being legacy code)?

There's a -Wweak-vtables which will point out a lot of these cases.  I have to warn you that in previous releases, it's still pretty experimental;  Doug Gregor has done a lot of work on it on ToT.

Another option is to run 'nm' on the objects/executables you're interested in.  For example, this file:

daysthatwere clang$ cat red.cpp
  #include <typeinfo>

  struct A {};
  struct B { virtual ~B(); };
  struct C { virtual ~C(); };
  C::~C() {}

  const std::type_info &test0() { return typeid(const char*); }
  const std::type_info &test1() { return typeid(const char**); }
  const std::type_info &test2() { return typeid(A); }
  const std::type_info &test3() { return typeid(B); }
  const std::type_info &test4() { return typeid(C); }

daysthatwere clang$ clang /tmp/red.cpp -c -o red.o
daysthatwere clang$ nm -m red.o | grep __ZTI | c++filt
0000000000000120 (__DATA,__datacoal_nt) weak external typeinfo for A
                 (undefined) external typeinfo for B
0000000000000150 (__DATA,__const) external typeinfo for C
                 (undefined) external typeinfo for char const*
0000000000000100 (__DATA,__datacoal_nt) weak external typeinfo for char const**

The "external" symbols are strong symbols provided by this object; these aren't a problem.
The "undefined external" symbols are expected to appear in a different object; these also aren't a problem.
The "weak external" symbols are the ones with vague linkage that you care about.

Otherwise, I don't have any magic bullets for you, sorry.

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

More information about the llvm-dev mailing list