[cfe-dev] -Wweak-vtables questions

[Somorjai, Akos]

Hi David,

Thanks for the answers! The whole reason I'm trying to use this warning is to detect possible RTTI problems with shared libraries (see http://gcc.gnu.org/faq.html#dso).

On Aug 30, 2012, at 6:00 PM, David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>>
 wrote:

On Thu, Aug 30, 2012 at 8:50 AM, Somorjai, Akos
<ASomorjai at graphisoft.com<mailto:ASomorjai at graphisoft.com>> wrote:
Hi all,

I'm currently experimenting with clang 3.1 (from Xcode 4.4 package on OS X
10.7), and I turned on the warning mentioned above. Most of the time it
gives the correct warning, but in some situations I'd need some
clarification:

classes defined in .cpp files — is the compiler warns me because
theoretically I can add this .cpp file into two separate modules/frameworks?

If the class is defined in an anonymous namespace then I believe we
can probably avoid emitting this as weak. (and/or just avoid the
warning at least - what it's meant to warn about (unnecessary overhead
of emitting the same vtable into multiple TUs & the link-time overhead
of having to deduplicate them all) isn't relevant when it's guaranteed
to be only in one TU)
So, your suggestion is to have an anonymous namespace around these classes? I'll give it a try.


pure virtual interface classes — is the warning necessary here?

Technically, yes (ish) - even pure virtual interface classes have to
have vtables (ABI requirement - there's well defined (failure)
behavior if you  call a pure virtual function). It might be debatable
as to what solution users should employ in this situation & whether or
not it's worthwhile/actionable to provide this warning - for those
willing to use this warning at all, I guess it might be worthwhile.
OK. So in this case I'll have to fall back to add a default implementation in a source file, and add that source file to the module/shared library. Which kind of kills the whole pure virtual interface stuff...

classes which are not exported from a module, so marked with
__attribute__((hidden))?

I'm not especially familiar with the visibility attributes, sorry. But
if I understand you correctly when you say 'module' you mean exporting
from, say, a shared library or executable? Yes, the warning is still
relevant there - the 'weakness' of the vtable symbol is only an issue
for compile/link time performance, it should have no effect on runtime
as far as I understand it.
We use several modules (shared libraries, frameworks).
The hidden attributes marks a class invisible for the executable or other modules, and the compiler knows about this, as it is a language feature. So it can also be a compile time issue.


Also, classes whose parent class is exported from a
module, but the derived class is not? — is the warning necessary here?

I don't believe derived classes enter into the rationale for this warning.

(that being said - this warning exists for a fairly specific use case
& may not be something you need. (even LLVM has a style requirement
for this but isn't anywhere near clean enough to turn the warning on
in its builds))

- David

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