私の共有ライブラリに重複したシンボル(外見上!)があるのはなぜですか(そしてどうやって)?

私の共有ライブラリに重複したシンボル(外見上!)があるのはなぜですか(そしてどうやって)?

エクスポートした共有ライブラリシンボルの単純なリストから、どのライブラリがどのシンボルをエクスポートしたかを調べる必要があります。リストには、各シンボルを手動で相互参照するのに十分なシンボル(20個程度)しかありません。

私はこれが役に立つ結果を生み出すようだと思いました。 2番目の列にリストされているアドレスを含む行をnm -A -D -f sysv <library-name>検索できました。FUNCそのため、すべてのエントリに対してこのコマンドを実行してファイルに/usr/libリダイレクトします。

驚くべきことに、ファイルを解析するスクリプトで私が行った完全性チェックで重複したシンボルが報告されました!調査の終わりに発見されたライブラリが重複したシンボルをエクスポートしていると思いますか? ! ?

私はいくつかのシェルスクリプトを使ってこれを確認し、私が使ったコマンドをこれに変更することができました技術的にライン:

readlink -f /lib/* /usr/lib/* \
  | grep -F .so. | sort | uniq \
  | while read x; do nm -A -D -f sysv $x; done \
  | grep FUNC | cut -d'|' -f1 | sort -g | uniq -c | sort -g \
  | sed -n '/^ \+1/!{s/^ \+[0-9]\+ \+//p}' | sed 's/ //g' \
  | tr '\n' '\v' \
  | sed ':1;s/\([^ ]\+\):\([^\v$]\+\)\v\1:/\1:\2|/g;t1' \
  | tr '\v' '\n' \
  | while IFS=: read -a x; do \
     nm -A -D -f sysv "${x[0]}" | grep ":\\(${x[1]//|/\\|}\\).*FUNC"; \
  done

上記のコマンドを実行すると、ディスクは短時間に移動します。必要に応じてチャンクに分割して一時ファイルにリダイレクトできます。返品出力範囲が非常に広いです。(〜150列)。

私は元々私が使用していたDebian Squeeze chrootで元のスクリプトを実行しましたが、chrootが正常に動作しているかどうかを調べるために、ホストシステムで上記のスクリプトを好奇心で実行しました。

うーん... chrootは90を超える重複項目を報告しますが、私のホストシステムには約267があるようです。

このコマンドはnmgrepの出力を介して動作するため、結果は少し複雑ですが、次のようになります。

/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_access|00043700|   T  |              FUNC|00000037|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_access|000436c0|   T  |              FUNC|0000003c|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_access_mask|000458f0|   T  |              FUNC|00000058|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_buffer_size|000432a0|   T  |              FUNC|00000037|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_buffer_size|00043260|   T  |              FUNC|0000003c|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_buffer_size_max|00044ff0|   T  |              FUNC|0000003c|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_buffer_size_max|00045030|   T  |              FUNC|00000037|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_buffer_size_min|000453c0|   T  |              FUNC|00000037|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_buffer_size_min|00045380|   T  |              FUNC|0000003c|     |.text

各シンボルには2つあります。住所が異なりますはい、しかし...私は動的接続がシンボル名を介して機能すると思いました。それがすべてです。私をさらに混乱させるのは、(上記のリストを右にスクロールすると)すべてのシンボルがFUNCその.textセクションの種類であるということです。

ここの後ろでどんな面白い魔法が起こるのかを知りたいので、この文を載せます。 (システムが稼働しているため...)

誰かが良いアイデアを持っている場合は、約600行のテキストをダンプできます。 Pastebinはもう人気がないようで、GitHubを使用しません。全体の出力を喜んで共有します。

ベストアンサー1

提供された情報nmが不完全なため、これらの記号は重複します。問題のシンボルにはバージョンが割り当てられます。次のコマンドを使用して表示できますobjdump -T

0000000000059d00 g    DF .text  0000000000000044 (ALSA_0.9)   snd_pcm_hw_params_get_access
0000000000056040 g    DF .text  000000000000004b  ALSA_0.9.0rc4 snd_pcm_hw_params_get_access

またはnmオプション--with-symbol-versions:

/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0:snd_pcm_hw_params_get_access|0000000000059d00|   T  |              FUNC|0000000000000044|     |.text@ALSA_0.9
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0:snd_pcm_hw_params_get_access|0000000000056040|   T  |              FUNC|000000000000004b|     |.text@@ALSA_0.9.0rc4

バイナリは特定のバージョンとシンボリックリンクされており、リンクすると正しいバージョンが得られます。これにより、以前のバージョンとの互換性を維持しながらAPIを変更できます。

おすすめ記事