[cfe-dev] -Wweak-vtables questions

[David Blaikie]

On Thu, Aug 30, 2012 at 9:46 AM, Somorjai, Akos
<ASomorjai at graphisoft.com> wrote:
> 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>
>  wrote:
>
> On Thu, Aug 30, 2012 at 8:50 AM, Somorjai, Akos
> <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.

I /think/ that should be a reasonable solution but I don't know if
Clang actually suppresses the warning (& better yet, can/does emit the
vtable strongly) in that case. I'd at least look into/ask around if
it's reasonable to fix it so Clang does this if it doesn't already
(excuse the vague/defensive language - I'm just not 100% sure so
that's all very much "pending further discussion")

>
>
> 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...

You already need to define the dtor (even if it's pure virtual) anyway
- so it's just a matter of putting that definition non-inline. (if,
for runtime performance reasons, you don't want the dtor to be
non-inline, you can define some arbitrary private virtual non-inline
function to act as the vtable anchor)

>
>
> 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.

Right - but even if it's not visible outside the module, it's still
visible across translation units within the module so you still have
the weak/strong differences (object file bloat, link time
deduplication) that -Wweak-vtables is trying to tell you about.

>
>
> 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
>
>