2012-01-09 8 views
3

私はABIクロスチェックツールを探していました。今、私は、このようなこれらの質問のように、他の質問で提案されているツールのいくつかを満たしている:ABI互換ヘッダ/ライブラリクロスチェック

How to test binary compatibility automatically?

Static analysis tool to detect ABI breaks in C++

を今、これは私が何をしようとしています正確に何ではありません - これらは、ABIを追跡してバージョン間で変更されます。

私は、与えられたプロジェクトのソースファイル+ライブラリヘッダーファイルとライブラリ.soファイルだけでなく、コンパイラのバージョン(ライブラリとプロジェクトの両方をコンパイルするために使用されている)が、 ABIの出力はコンパイルされたライブラリと一致しますか?

これは、アップストリームライブラリがlibfoo.soとlibfood.soを出荷した場合に適用される状況です。食べ物が少し違うABI(フロートの代わりに二重と言います)ですが、それほど遠くなくてはコンパイルできません。

  • コンパイルされた実行可能ファイルが正しいlibにリンクされているというテスト(防弾ではない可能性があります)がありますか?
  • これを行うツールはありますか?

答えて

1

libfoo.soがCでコード化されていると仮定している場合は、ヘッダーファイルを持たなくても、それを知る方法はありません。共有オブジェクトのシンボルテーブルには型情報が含まれていないので(通常の知恵以外の何もライブラリには、通常の処理を行う代わりに2つの整数を加算して返す関数が含まれています)ヒープ割り当て)。

したがって、libfoo.soは悪用される可能性があります。しかし、通常、いくつかの共有ライブラリのシンボルに関連付けられているバージョンがあります(ライブラリがdlopenの場合は、dlvsymを使ってプログラムでそれを照会できます)。バージョンを生成するにはいくつかの方法があります。

ライブラリが純粋なC++の場合、シンボルはmangledなので、そのエンコーディングには署名が含まれています。

ライブラリのバージョンを返すライブラリ内にいくつかの機能を持たせることをお勧めします。良い例としては、glib version information関数を見てください。

1

ABI compliance checkerは、アプリケーションが2つのライブラリ間の変更にさらされているかどうかを確認することもサポートされているようです。