RTTI handling

Hello all,

I was wondering how llvm and clang handles the RTTI shared libraries issue mentioned here: http://gcc.gnu.org/faq.html#dso

Is it using name or address comparison?

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…

(Mac OS X 10.6/10.7, clang 3.0)

Thanks,

Ákos Somorjai
Developer Support Manager

GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 | asomorjai@graphisoft.com

LLVM does not use RTTI–it has its own mechanisms; see llvm/include/llvm/Support/Casting.h, and by default it is turning off for an LLVM build.

Garrison

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.

I don’t think that’s what the OP meant.

I think he’s talking about using RTTI in his code - how LLVM generated code (and/or LLVM runtime libraries) handle RTTI.
I expect the answer is "The same as gcc, since code compiled with LLVM needs to interoperate with code compiled with gcc.

[ I too would like a better way of handling RTTI and dynamic libraries ]

– Marshall

Marshall Clow Idio Software <mailto:mclow.lists@gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
– Yu Suzuki

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

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

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.

Thanks, John. I’ll experiment with both the warning and the nm-weak external tool, and let you know the results.

Best, Akos

John,

I’m trying to use this warning to check the vtable problem. Here’s an example

In mem.hpp

class AA {

// Construction / destruction:

protected:

AA ();

AA (const AA&); // Disabled

public:

virtual ~AA ();

};

In mem.cpp

#include “mem.hpp”

AA::~AA()

{

}

And I still get the following warning:

warning: ‘AA’ has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [-Wweak-vtables,3]

What am I doing wrong? Shall I declare the destructor to be pure virtual (then the warning goes away)? This is not always an option, because not all of these classes are ABCs.

Thanks,

Akos

Which version of Clang are you using? Like I said, this warning was still experimental even a few months ago, and it’s gotten a lot of attention on ToT. In particular, this case no longer warns.

John.

Apple clang version 3.0 (tags/Apple/clang-211.9) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.8.0

It’s part of the Xcode 4.2b7 package.

Shall I try to compile it on my own?

Thanks, Akos

John,

The version from the Xcode 4.2 GM package (Apple clang version 3.0 (tags/Apple/clang-211.10.1)) still has the same problem. Which version should I use?

Thanks, Akos

It looks like you’ll have to compile your own from trunk if you want this warning improvement, sorry. Obviously, that’s not an Apple-supported option, but it’s a people-on-this-list-supported one. :slight_smile:

John.

John,

Is there any progress regarding RTTI handling in the newer builds?

Thanks,

Akos

When you’re resurrecting six-month-old threads, it’s polite to quote some history. :slight_smile:

I don’t know offhand what the state of this warning is in Xcode 4.3, and I
can’t comment on potential future releases. If this matters a lot to you,
please just try it and file bugs for any actionable problems you see.

John.

Thanks, John, and sorry for being impolite… I still have the thread in my inbox, so for me it was just a simple follow-up.

Thanks again,

Ákos Somorjai
Developer Support Manager

GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 | asomorjai@graphisoft.com