例:
$ objdump Logger.cpp.o -t
00000000 g F .text 00000000 .hidden __sti___10_Logger_cpp_0b2ae32b
これは、シンボルの可視性が隠されていることを意味します: https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html
シンボルの可視性を変更する理由は次のとおりです。
詳細については、 http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.htmlを参照してください。
可視性のサポートを説明するリンク(gccの場合)
リンクから:
これにより、DSO(動的共有オブジェクト)のロード時間が大幅に改善されます。たとえば、テストされた巨大なC ++テンプレートベースのライブラリ(TnFOX Boost.Pythonバインディングライブラリ)は、6分以上ではなく8秒で読み込まれるようになりました。
これにより、オプティマイザーはより優れたコードを生成できます。PLTの間接参照(PICコードなどのグローバルオフセットテーブルを介して関数呼び出しまたは変数アクセスを検索する必要がある場合)を完全に回避できるため、最新のプロセッサでのパイプラインストールを大幅に回避し、コードを大幅に高速化できます。さらに、ほとんどのシンボルがローカルでバインドされている場合、DSO全体で安全に完全に削除(削除)できます。これにより、特に「万が一に備えて」エントリポイントを維持する必要がなくなったインライナーに大きな自由度が与えられます。
DSOのサイズを5〜20%削減します。ELFのエクスポートされたシンボルテーブル形式はかなりスペースを占有し、完全なマングルされたシンボル名を与えます。これは、テンプレートを頻繁に使用すると、平均で約1000バイトになる可能性があります。C ++テンプレートは大量のシンボルを吐き出し、典型的なC ++ライブラリは約5〜6Mbの30,000シンボルを簡単に超えることができます。したがって、不要なシンボルの60〜80%を切り取ると、DSOをメガバイト小さくすることができます。
シンボルの衝突の可能性がはるかに低くなります。異なるものに同じシンボルを内部的に使用している2つのライブラリの古い問題は、このパッチでようやく私たちの背後にあります。ハレルヤ!
上で引用したライブラリは極端なケースですが、新しい可視性のサポートにより、エクスポートされたシンボルテーブルが200,000を超えるシンボルから18,000未満に減少しました。いくつかの21Mbもバイナリサイズからノックオフされました!
使用サンプルと、可視性属性を使用する場合の潜在的な落とし穴