4

起動時に.soファイルをプラグインとしてロードするアプリケーションを持っています.dlopen()

ビルド環境は x86 ハードウェアで実行されていますが、アプリケーションは別のプラットフォーム用にクロス コンパイルされています。

アプリケーションを実際にデプロイすることなく、(自動ビルド プロセスの一部として) .so ファイルとアプリケーションの組み合わせに未解決のシンボルがないことを確認するチェックを行うことができれば素晴らしいことです。

の出力を使用してシンボルをテストするスクリプトを作成する前に、nmこれを既に実行しているユーティリティを誰か知っているかどうか疑問に思っています。

編集1：説明をわずかに変更しました-.soでシンボルをテストしようとしているだけでなく、いくつかの.soとアプリケーション自体の組み合わせでテストしようとしています-つまり. アプリケーションがすべての .so をロードした後、まだ未解決のシンボルがあるかどうか。

回答で示唆されているように (Martin v. Löwis と tgamblin に感謝)、nm単一のファイルで欠落しているシンボルを簡単に識別できますが、それらのシンボルのどれが他のロードされたモジュールの 1 つで解決されたかを簡単に識別できません。

4

3 に答える 3

2

クロス nm ツールがクロス コンパイラ スイートの一部であることが理想的です。たとえば、クロス コンパイル用に GNU binutils をビルドすると、クロス nm も (クロス objdump と共に) 提供されます。

于 2008-11-06T22:37:05.507 に答える
1

の制限はnm、包括的なシンボルチェッカーには使用できないことを意味することが判明しました。特に、nmエクスポートされたシンボルのみを一覧表示します。

ただし、readelfライブラリのすべての依存関係とともに、包括的なリストが作成されます。

使用readelfするスクリプトを作成することは可能でした：使用されるすべてのライブラリのリストを作成する、実行可能ファイル（または.so）でシンボルのリストを作成する未解決のシンボルのリストを作成する-未解決のシンボルがある場合この時点で、ロード時にエラーが発生していました。

その後、新しいライブラリが見つからなくなるまでこれが繰り返されます。

これが実行可能ファイルとすべてのdlopen()ed.soファイルに対して行われると、実行時に発生する未解決の依存関係を適切にチェックできます。

于 2009-03-27T00:45:19.843 に答える
1

これに ldd の再帰バージョンを使用できますか? 誰かが役立つスクリプトを書いたようです。これは少なくとも、最初に .so で正しく指定されていれば、すべての依存ライブラリを解決できることを示しています。すべての依存関係がリンカー オプションを使用して .so で参照されることを保証できます。これに加えて、再帰的な ldd により、未解決のシンボルがないことが保証されます。

多くの場合、リンカには、共有ライブラリ内の未解決のシンボルをエラーにするオプションがあり、これを使用して、まったくチェックする必要がないようにすることができます。GNU ld の場合、 --no-allow-shlib-undefined を渡すだけで、.so を作成した場合、未解決のシンボルがないことが保証されます。GNU ld ドキュメントから:

   --no-undefined
       Report  unresolved  symbol  references  from regular object files.
       This is done even if the linker is creating a non-symbolic shared 
       library.  The switch --[no-]allow-shlib-undefined controls the 
       behaviour for reporting  unresolved references found in shared
       libraries being linked in.

   --allow-shlib-undefined
   --no-allow-shlib-undefined
       Allows (the default) or disallows undefined symbols in shared 
       libraries.  This switch is  similar  to  --no-undefined  except
       that  it determines the behaviour when the undefined symbols are
       in a shared library rather than a regular object file.  It does 
       not affect how undefined symbols in regular object files are 
       handled.

       The reason that --allow-shlib-undefined is the default is that the 
       shared library being specified  at  link  time may  not  be  the  
       same as the one that is available at load time, so the symbols might 
       actually be resolvable at load time.  Plus there are some systems, 
       (eg BeOS) where undefined symbols in shared libraries is  normal.   
       (The kernel patches them at load time to select which function is most
       appropriate for the current architecture.  This is used for example to
       dynamically select an appropriate memset function).  Apparently it is 
       also normal for HPPA shared libraries to have undefined symbols.

リンク後のチェックを行う場合は、nm がおそらく最善の策であるという Martin 氏の意見に同意します。私は通常、出力の ' U ' を grep して、未解決のシンボルをチェックするだけなので、書くのはかなり簡単なスクリプトになると思います。

于 2008-11-06T22:45:07.953 に答える