|
|
楼主 |
发表于 2006-3-17 18:33:23
|
显示全部楼层
http://gcc.gnu.org/wiki/Visibility
Visibility
Note: the text on this page was almost integrally written by Niall Douglas, the original author of the patch, and placed in his website. This is basically a local mirror (especially useful because the website now appears to be down).
Why is the new C++ visibility support so useful?
Put simply, it hides most of the ELF symbols which would have previously (and unnecessarily) been public. This means:
It very substantially improves load times of your DSO (Dynamic Shared Object).
For example, a huge C++ template-based library which was tested (the TnFOX Boost.Python bindings library) now loads in eight seconds rather than over six minutes!
It lets the optimiser produce better code.
PLT indirections (when a function call or variable access must be looked up via the Global Offset Table such as in PIC code) can be completely avoided, thus substantially avoiding pipeline stalls on modern processors and thus much faster code. Furthermore when most of the symbols are bound locally, they can be safely elided (removed) completely through the entire DSO. This gives greater latitude especially to the inliner which no longer needs to keep an entry point around "just in case".
It reduces the size of your DSO by 5-20%.
ELF's exported symbol table format is quite a space hog, giving the complete mangled symbol name which with heavy template usage can average around 1000 bytes. C++ templates spew out a huge amount of symbols and a typical C++ library can easily surpass 30,000 symbols which is around 5-6Mb! Therefore if you cut out the 60-80% of unnecessary symbols, your DSO can be megabytes smaller!
Much lower chance of symbol collision.
The old woe of two libraries internally using the same symbol for different things is finally behind us with this patch. Hallelujah!
Although the library quoted above is an extreme case, the new visibility support reduced the exported symbol table from > 200,000 symbols to less than 18,000. Some 21Mb was knocked off the binary size as well!
Some people may suggest that GNU linker version scripts can do just as well. Perhaps for C programs this is true, but for C++ it cannot be true - unless you labouriously specify each and every symbol to make public (and the complex mangled name of it), you must use wildcards which tend to let a lot of spurious symbols through. And you have to update the linker script if you decide to change names to the classes or the functions. In the case of the library above, the author couldn't get the symbol table below 40,000 symbols using version scripts. Furthermore, using linker version scripts doesn't permit GCC to better optimise the code.
Windows compatibility
For anyone who has worked on any sizeable portable application on both Windows and POSIX, you'll know the sense of frustration that non-Windows builds of GCC don't offer an equivalent to __declspec(dllexport), i.e. the ability to mark your C/C++ interface as being that of the shared library. Frustration because good DSO interface design is just as important for healthy coding as good class design, or correctly opaquing internal data structures.
While the semantics can't be the same with Windows DLL's and ELF DSO's, almost all Windows-based code uses a macro to compile-time select whether dllimport or dllexport is being used. This mechanism can be easily reused with this patch so adding support to anything already able to be compiled as a Windows DLL is literally a five minute operation.
Note: The semantics are not the same between Windows and this GCC feature - for example, __declspec(dllexport) void (*foo)(void) and void (__declspec(dllexport) *foo)(void) mean quite different things whereas this generates a warning about not being able to apply attributes to non-types on GCC.
Still not convinced?
A further reading on the subject of good DSO design is this article by Ulrich Drepper (lead maintainer of GNU glibc).
How to use the new C++ visibility support
In your header files, wherever you want an interface or API made public outside the current DSO, place __attribute__ ((visibility("default"))) in struct, class and function declarations you wish to make public (it's easier if you define a macro as this). You don't need to specify it in the definition. Then, alter your make system to pass -fvisibility=hidden to each call of GCC compiling a source file. If you are throwing exceptions across shared object boundaries see the section "Caveats" below. Use nm -C -D on the outputted DSO to compare before and after to see the difference it makes.
Some examples of the syntax:
#ifdef _MSC_VER
#ifdef BUILDING_DLL
#define DLLEXPORT __declspec(dllexport)
#else
#define DLLEXPORT __declspec(dllimport)
#endif
#define DLLLOCAL
#else
#ifdef HAVE_GCCVISIBILITYPATCH
#define DLLEXPORT __attribute__ ((visibility("default")))
#define DLLLOCAL __attribute__ ((visibility("hidden")))
#else
#define DLLEXPORT
#define DLLLOCAL
#endif
#endif
extern "C" DLLEXPORT void function(int a);
class DLLEXPORT SomeClass
{
int c;
DLLLOCAL void privateMethod(); // Only for use within this DSO
public:
Person(int _c) : c(_c) { }
static void foo(int a);
};
This also helps producing more optimised code: when you declare something defined outside the current compiland, GCC cannot know if that symbol resides inside or outside the DSO in which the current compiland will eventually end up; so, GCC must assume the worst and route everything through the GOT (Global Offset Table) which carries overhead both in code space and extra (costly) relocations for the dynamic linker to perform. To tell GCC a class, struct, function or variable is defined within the current DSO you must specify hidden visibility manually within its header file declaration (using the example above, you declare such things with DLLLOCAL). This causes GCC to generate optimal code.
But this is of course cumbersome: this is why -fvisibility was added. With -fvisibility=hidden, you are telling GCC that every declaration not explicitally marked with a visbility attribute has a hidden visibility. And like in the example above, even for classes marked as visibile (exported from the DSO), you may still want to mark e.g. private members as hidden, so that optimal code will be produced when calling them (from within the DSO).
To aid you converting old code to use the new system, GCC now supports also a #pragma GCC visibility command:
extern void foo(int);
#pragma GCC visibility push(hidden)
extern void someprivatefunct(int);
#pragma GCC visibility pop
You should really only use this for legacy code. All new code should specify each declaration as exported or local individually.
Lastly, there's one other new command line switch: -fvisibility-inlines-hidden. This causes all inlined class member functions to have hidden visibility, causing significant export symbol table size & binary size reductions though not as much as using -fvisibilty=hidden. However, -fvisibility-inlines-hidden can be used with no source alterations - simply apply and win!
Problems with C++ exceptions (please read!)
Exception catching of a user defined type in a binary other than the one which threw the exception requires a typeinfo lookup. Go back and read that last statement again. When exceptions start mysteriously malfunctioning, the cause is exactly this one!
The obvious first step is to mark all types throwable across shared object boundaries always as default visibility. We suggest a parameterised macro eg; EXCEPTIONAPI(spec) which becomes (in the example above) DLLEXPORT on Win32 but always __attribute__ ((visibility("default"))) on GCC. You must do this because even if (e.g.) the exception type's implementation code lives in DLL A, when DLL B throws an instance of that type, the catch handler in DLL C will look for the typeinfo in DLL B.
However, this isn't the full story - it gets harder. The GNU linker treats typeinfo symbols a bit specially - it keeps a table of them which it marks off against each object file it processes when forming the output binary. Symbol visibility is "default" by default but if it encounters just one definition with it hidden - just one - that typeinfo symbol becomes permanently hidden (remember the C++ standard's ODR - one definition rule). Remember that typeinfo symbols are defined on demand within each object file compiled at the point of first use and are defined weakly so the definitions get merged at link time into one copy.
The upshot of this is that if you forget your preprocessor defines in just one object file, or if at any time a throwable type is not declared explicitly public, the -fvisibility=hidden will cause it to be marked hidden in that object file which causes the typeinfo to vanish in the outputted binary (which then causes any throws of that type to cause terminate() to be called in the catching binary). This behaviour only applies to the typeinfo - the vtable and everything else appears fine, so your binaries will link perfectly and appear to work correctly, even though they don't.
While it would be lovely to have a warning for this, there are plenty of legitimate reasons to keep throwable types out of public view. And until whole program optimisation or the export keyword is added to GCC, the compiler can't know which throws are caught locally.
Step-by-step guide
The following instructions are how to add full support to your library, yielding the highest quality code with the greatest reductions in binary size, load times and link times. All new code should have this support from the beginning! And it's worth your while especially in speed critical libraries to spend the few days required to implement it fully - it's a once off investment of time with nothing but good resulting forever more. You can however add basic support to your library in far less time though it is not recommended that you do so.
Place something along the lines of the following code in your master header file (or a specific header that you will include everywhere). This code is taken from the aforementioned TnFOX library:
// Shared library support
#ifdef WIN32
#define FXIMPORT __declspec(dllimport)
#define FXEXPORT __declspec(dllexport)
#define FXDLLLOCAL
#define FXDLLPUBLIC
#else
#define FXIMPORT
#ifdef GCC_HASCLASSVISIBILITY
#define FXEXPORT __attribute__ ((visibility("default")))
#define FXDLLLOCAL __attribute__ ((visibility("hidden")))
#define FXDLLPUBLIC __attribute__ ((visibility("default")))
#else
#define FXEXPORT
#define FXDLLLOCAL
#define FXDLLPUBLIC
#endif
#endif
// Define FXAPI for DLL builds
#ifdef FOXDLL
#ifdef FOXDLL_EXPORTS
#define FXAPI FXEXPORT
#else
#define FXAPI FXIMPORT
#endif // FOXDLL_EXPORTS
#else
#define FXAPI
#endif // FOXDLL
// Throwable classes must always be visible on GCC in all binaries
#ifdef WIN32
#define FXEXCEPTIONAPI(api) api
#elif defined(GCC_HASCLASSVISIBILITY)
#define FXEXCEPTIONAPI(api) FXEXPORT
#else
#define FXEXCEPTIONAPI(api)
#endif
Obviously, you may wish to replace the =FX? with a prefix suiting your library and for projects also supporting Win32, you'll find a lot of the above familiar (you can reuse most of your Win32 macro machinery to also support GCC). To explain:
If WIN32 is defined (as is usual when building for Windows):
If FOXDLL_EXPORTS is defined, we are building our library and symbols should be exported. Something ending with _EXPORTS is defined by MSVC by default in all projects.
If FOXDLL_EXPORTS is not defined, we are importing our library and symbols should be imported.
If WIN32 is not defined (as is usual when building for Unix with GCC):
If GCC_HASCLASSVISIBILITY is defined, then GCC supports the new features. You should define this in your make system if GCC's version is 4.0 or later. Or you may make it configurable.
For every non-templated non-static function definition in your library (both headers and source files), decide if it is publicly used or internally used:
If it is publicly used, mark with FXAPI like this: extern FXAPI PublicFunc()
If it is only internally used, mark with FXDLLLOCAL like this: extern FXDLLLOCAL PublicFunc()
Remember, static functions need no demarcation, nor does anything which is templated.
For every non-templated class definition in your library (both headers and source files), decide if it is publicly used or internally used:
If it is publicly used, mark with FXAPI like this: class FXAPI PublicClass
If it is only internally used, mark with FXDLLLOCAL like this: class FXDLLLOCAL PublicClass
An exception is types which can be thrown as an exception across a shared object boundary - these require special demarcation: class FXEXCEPTIONAPI(FXAPI) PublicThrowableClass. You need not do this for types which are never thrown across a shared object boundary.
Individual member functions of an exported class, in particular ones which are private, non-virtual, and are not used by friendly code, should be marked individually with FXDLLLOCAL.
In your build system (Makefile etc), you will need to define the GCC_HASCLASSVISIBILITY if GCC is v4.0 or later and the user has configured in support. You will probably also wish to add the -fvisibility=hidden and -fvisibility-inlines-hidden options to the command line arguments of every GCC invocation. Remember to test your library thoroughly afterwards, including that all exceptions correctly traverse shared object boundaries.
If you want to see before and after results, use the command nm -C -D <library>.so which lists in demangled form all exported symbols. |
|
IP卡
狗仔卡
发表于 2006-3-17 18:31:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡