[LLVMdev] RTTI handling

[Somorjai, Akos]

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>