Bug 28786 - No way set visibility of typeinfo without setting VTT and vtable similarly
Summary: No way set visibility of typeinfo without setting VTT and vtable similarly
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.1.2
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-20 23:57 UTC by Andrew Miller
Modified: 2008-12-23 11:54 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Miller 2006-08-20 23:57:58 UTC
There is currently no way to set the visibility of the typeinfo, except by setting the visibility of the VTT and vtable.

This is unfortunate if you want to be able to using RTTI features on a class from another module, but don't want to export VTTs and vtables.

It is unclear what the best attribute name to tell gcc that you want this is, but something like:

class Foo
  : public virtual Bar
{
public:
  virtual void doSomething();
} __attribute__((visibility("hidden"))) __attribute__((typeinfo_visibility("default")));

seems reasonable.
Comment 1 Andrew Pinski 2006-08-21 01:21:50 UTC
I don't see why this is a problem?  In fact I think you can get into a problem with the C++ One definition rules.
Comment 2 Andrew Miller 2006-08-21 01:48:55 UTC
(In reply to comment #1)
> I don't see why this is a problem?

One of the main uses for visibility is to hide symbols to reduce the size of shared objects, and to ensure that people don't use libraries in ways which are inappropriate.

In this case, if I know that no external code is going to extend from Foo, but will perform dynamic_cast<Foo*>(ptr), I have to ensure that _ZTI3Foo is not hidden. However, since there is no way to do this:

1) I have no choice but to also export _ZTV3Foo, _ZTT3Foo, and possibly a number of construction vtables. This means that I have a larger than necessary set of visible symbols, which increases the size of the binary, as well as link times.
2) External code can link against the library, and extend from Foo. However, in a subsequent version of the library (which is supposed to be binary compatible) the meaning of protected members might change, causing unexpected problems.
3) This could allow for the compiler to perform space optimisations in the future (for example, dropping construction vtables which are never needed, and are also hidden).

> In fact I think you can get into a problem
> with the C++ One definition rules.
I'm not saying that this should be supported in order to allow for the same name to be used in another compilation unit, and in fact, if you wanted to do this you would hide everything, or the typeinfo would conflict.
Comment 3 Pawel Sikora 2008-12-23 11:54:10 UTC
(In reply to comment #0)
> There is currently no way to set the visibility of the typeinfo, except by
> setting the visibility of the VTT and vtable.

isn't -fvisibility-ms-compat (from recent gcc) enough for you?