abicompat - クラウドでオンライン

プログラム：

NAME

abicompat - ABI の互換性をチェックする

abicompat は、特定の共有ライブラリにリンクするアプリケーションがまだ有効であることを確認します
そのライブラリの後続バージョンと互換性のある ABI。 新しいバージョンの
ライブラリが ABI の非互換性を導入し、次に abicompat がユーザーに正確に何を示唆するかを示します
その非互換性です。

呼び出し

abicompat [オプション] [ ]

OPTIONS

· - 助けて

コマンドに関する短いヘルプを表示して終了します。

· - バージョン | -v

プログラムのバージョンを表示して終了します。

· --リスト-未定義のシンボル | -u

アプリケーションの未定義シンボルの一覧を表示して終了します。

· --show-base-names | -b

ツールによって生成された結果のレポートでは、このオプションはアプリケーションを作成し、
ライブラリはベース名のみで参照できます。 完全な絶対名ではありません。 これ
アプリケーションの名前を比較したいスクリプトで使用すると便利です。
ライブラリは、ディレクトリ名とは無関係です。

· --app-デバッグ情報ディレクトリ

アプリケーションのデバッグ情報があるディレクトリへのパスを設定します
配置されるはずです。 これは、デバッグが必要なアプリケーション バイナリに役立ちます。
info は別のファイル セットにあります。

· --lib-デバッグ情報-ディレクトリ1

最初のバージョンのデバッグ情報があるディレクトリへのパスを設定します
共有ライブラリのレイアウトが想定されています。 これは共有ライブラリに役立ちます
デバッグ情報が別のファイル セットにあるバイナリ。

· --lib-デバッグ情報-ディレクトリ2

XNUMX 番目のバージョンのデバッグ情報があるディレクトリへのパスを設定します。
共有ライブラリのレイアウトが想定されています。 これは共有ライブラリに役立ちます
デバッグ情報が別のファイル セットにあるバイナリ。

· --no-show-locs
の場所に関する情報を表示しないでください。 2番目の shared ライブラリ それぞれ
タイプが変更されました。

· -- 弱モード

これにより、弱いモードがトリガーされます アビコンパット. このモードでは、
ライブラリが必要です。 つまり、 abicompat は次のように呼び出されます。

abicompat --weak-mode

なお、 -- 弱モード のバージョンが XNUMX つしかない場合は、オプションを省略できます。
アプリケーションと共にライブラリが提供されます。 その場合、 アビコンパット 自動的に
弱いモードで動作するように切り替えます。

アビコンパット

この弱いモードでは、ライブラリによってエクスポートされる関数と変数の型と
アプリケーションによって消費されます (これらの関数と変数のシンボルのように)
アプリケーションでは定義されておらず、ライブラリによって定義およびエクスポートされている)
アプリケーションが期待するこれらのタイプのバージョンと比較します。 そして、これらの場合
タイプの XNUMX つのバージョンが異なります。 アビコンパット ユーザーに違いを伝える
です。

つまり、このモードでは、 アビコンパット 関数の型と
ライブラリによってエクスポートされた変数は、アプリケーションが
ABIに関する限り、期待しています。

このモードでは、 アビコンパット エクスポートされた関数または変数を検出しません
(シンボル) アプリケーションによって期待されているが、ライブラリから削除されています。
それがそれが呼ばれる理由です 弱い モード。

リターン VALUES

の終了コード アビコンパット バイナリの ABI が
比較された値は等しいか、異なる場合、またはツールでエラーが発生した場合は非ゼロになります。

後者の場合、終了コードは 8 ビット幅のビット フィールドであり、各ビットには
具体的な意味。

名前付きの値 1 の最初のビット ABIDIFF_ERROR エラーがあったことを意味します。

名前付きの値 2 の XNUMX 番目のビット ABIDIFF_USAGE_ERROR 途中でエラーが発生したことを意味します
ユーザーがツールを呼び出しました。 たとえば、ユーザーがツールを呼び出した場合に設定される可能性があります
不明なコマンド ライン スイッチ、間違った番号または引数など。このビットが
設定し、次に ABIDIFF_ERROR ビットも設定する必要があります。

値 4 の XNUMX 番目のビット、名前付き ABIDIFF_ABI_CHANGE バイナリの ABI が
比べて違います。

値 8 の XNUMX 番目のビット、名前付き ABIDIFF_ABI_INCOMPATIBLE_CHANGE のABIを意味します
比較されるバイナリは、互換性のない方法で異なります。 このビットが設定されている場合、
ABIDIFF_ABI_CHANGE ビットも設定する必要があります。 もし ABIDIFF_ABI_CHANGE が設定され、
ABIDIFF_INCOMPATIBLE_CHANGE is NOT 設定されている場合、比較される ABI が
または対応していない可能性があります。 その場合、人間が ABI の変更を確認する必要があります。
互換性があるかどうかを判断します。

残りのビットは当面使用されません。

USAGE 例

· 新しい共有ライブラリ バージョンでの ABI 非互換性の可能性の検出:

$ cat -n test0.h
1 つの構造体 foo
2{
3 int m0;
4
5 フー()
6 : m0()
7 {}
8};
9
10 フィート*
11 first_func();
12
13 ボイド
14 second_func(foo&);
15
16 ボイド
17 第三機能();
$

$ cat -n テストアプリ.cc
1 // コンパイル:
2 // g++ -g -Wall -o テストアプリ -L. -ltest-0 test-app.cc
3
4 #include "test0.h"
5
6 整数
7 メイン()
8{
9 foo* f = first_func();
10 秒関数(*f);
11 リターン 0;
12}
$

$ cat -n test0.cc
1 // これを次のようにコンパイルします。
2 // g++ -g -Wall -shared -o libtest-0.so test0.cc
3
4 #include "test0.h"
5
6 フィート*
7 first_func()
8{
9 foo* f = 新しい foo();
10 リターン f;
11}
12
13 ボイド
14 second_func(foo&)
15{
16}
17
18 ボイド
19 第三関数()
20{
21}
$

$ cat -n test1.h
1 つの構造体 foo
2{
3 int m0;
4 文字 m1; /* <-- 新しいメンバーがここに追加されました! */
5
6 フー()
7 : m0()、
8m1()
9 {}
10};
11
12 フィート*
13 first_func();
14
15 ボイド
16 second_func(foo&);
17
18 ボイド
19 第三機能();
$

$ cat -n test1.cc
1 // これを次のようにコンパイルします。
2 // g++ -g -Wall -shared -o libtest-1.so test1.cc
3
4 #include "test1.h"
5
6 フィート*
7 first_func()
8{
9 foo* f = 新しい foo();
10 リターン f;
11}
12
13 ボイド
14 second_func(foo&)
15{
16}
17
18 /* third_func() の定義をコメントアウトしましょう
19 ボイド
20 第三関数()
21{
22}
23 */
$

· ライブラリの最初と XNUMX 番目のバージョンをコンパイルします。 libtest-0.so &
libtest-1.so:

$ g++ -g -Wall -shared -o libtest-0.so test0.cc
$ g++ -g -Wall -shared -o libtest-1.so test1.cc

· アプリケーションをコンパイルし、ライブラリの最初のバージョンに対してリンクします。
の作成 テストアプリ バイナリ：

$ g++ -g -Wall -o テストアプリ -L。 -ltest-0.so テスト-app.cc

・さあ、使って アビコンパット libtest-1.so がアプリと ABI 互換であるかどうかを確認します。
libtest-0.so の ABI に:

$ abicompat テストアプリ libtest-0.so libtest-1.so
ELF ファイル「test-app」は、以下の「libtest-1.so」との違いにより、「libtest-0.so」との ABI 互換性がない可能性があります。
機能変更の概要: 0 削除、2 変更、0 追加機能
変数の変更の概要: 0 個の削除、0 個の変更、0 個の変数の追加

いくつかの間接的なサブタイプの変更を伴う 2 つの関数:

[C]'function foo* first_func()' には、いくつかの間接的なサブタイプの変更があります:
戻り値の型が変更されました:
タイプ「struct foo」を指している：
サイズが 32 ビットから 64 ビットに変更されました
1 データ メンバーの挿入:
'char foo::m1'、オフセット 32 (ビット単位)
[C]'function void second_func(foo&)' には、いくつかの間接的なサブタイプの変更があります。
タイプ 'foo&' のパラメータ 0 には、サブタイプの変更があります:
以前に報告されたように、参照される型「struct foo」が変更されました

$

· 今は abicompat の弱いモードを使用します。つまり、アプリケーションと
ライブラリの新しいバージョン:

$ abicompat --weak-mode テストアプリ libtest-1.so
ライブラリで定義された関数
「libtest-1.so」
どのアプリケーションとは異なるサブタイプがありますか
「テストアプリ」
期待するもの:

関数 foo* first_func():
戻り値の型が変更されました:
タイプ「struct foo」を指している：
サイズが 32 ビットから 64 ビットに変更されました
1 データ メンバーの挿入:
'char foo::m1'、オフセット 32 (ビット単位)

$

onworks.net サービスを使用して abicompat オンラインを使用する