12

例:

$ objdump Logger.cpp.o  -t

00000000 g     F .text  00000000 .hidden __sti___10_Logger_cpp_0b2ae32b
4

2 に答える 2

3

これは、シンボルの可視性が隠されていることを意味します: https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html

シンボルの可視性を変更する理由は次のとおりです。

  • シンボル衝突のリスクが少ない。
  • 小さいバイナリ。
  • 動的リンカが多くのシンボルを処理する必要がないため、起動時間が短縮されました。
  • コンパイラは、LD_PRELOAD タイプのシステムを介してシンボルをオーバーライドできないことを認識しているため、より効率的なコードを作成できる可能性があります。
  • 文書化されていない API へのサードパーティ ソフトウェア呼び出しの防止。

詳細については、 http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.htmlを参照してください。

于 2012-07-04T13:16:23.027 に答える
1

可視性のサポートを説明するリンク(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もバイナリサイズからノックオフされました!

使用サンプルと、可視性属性を使用する場合の潜在的な落とし穴

于 2012-07-04T13:32:20.950 に答える