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)? Currently I don't know any better way than runtime logging and asserting. Also, what shall we do we external source libraries (like Teigha from Open Design Alliance), where we don't really have any control? Just being curious, Akos From: John McCall <rjmccall at apple.com<mailto:rjmccall at apple.com>> Date: Fri, 30 Sep 2011 10:22:02 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>" <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>> Subject: Re: [LLVMdev] RTTI handling On Sep 30, 2011, at 9:15 AM, Somorjai, Akos wrote: I was wondering how llvm and clang handles the RTTI shared libraries issue mentioned here: http://gcc.gnu.org/faq.html#dso This is really a Clang question and so belongs on cfe-dev. Is it using name or address comparison? Clang strives for interoperability with GCC, which means we use address comparison on targets where GCC does. Therefore yes, we have the same issues with symbol visibility and vague linkage. We have an architecture with several frameworks and plug-ins; some of the latter are being loaded and unloaded runtime. In the past that issue caused crashes in our app, so at the moment we are overriding __dynamic_cast to detect this problem, but that's kind of messy. I'm hoping for a better solution with llvm… The best solution, bar none, is to avoid the need for vague linkage on your RTTI objects. If they correspond to polymorphic class types, which presumably they do if your problems are with dynamic_cast, then you need to use key functions more effectively. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110930/8355c025/attachment.html>
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. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110930/c4f649c3/attachment.html>
Thanks, John. I'll experiment with both the warning and the nm-weak external
tool, and let you know the results.
Best, Akos
From: John McCall <rjmccall at apple.com<mailto:rjmccall at
apple.com>>
Date: Fri, 30 Sep 2011 15:24:33 -0700
To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at
graphisoft.com>>
Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>"
<llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>
Subject: Re: [LLVMdev] RTTI handling
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.
John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110930/c5af3456/attachment.html>