addr2line の 2 つの代替案を次に示します。 .適切なターゲットのツールチェーンがあると仮定すると、次のいずれかを実行できます:
objdump を使用 :
vmlinux を見つけます または .ko ファイルをカーネル ルート ディレクトリの下に置き、オブジェクト ファイルを逆アセンブルします:
objdump -dS vmlinux > /tmp/kernel.s
生成されたアセンブリ ファイル /tmp/kernel.s を開きます . vim などのテキスト エディタで . unwind_backtrace+0x0/0xf8 に移動 、つまり unwind_backtrace のアドレスを検索します + offset .最後に、ソース コードで問題のある部分を特定しました。
gdb を使用 :
IMO、さらにエレガントなオプションは、唯一無二の gdb を使用することです .ホスト マシンに適切なツールチェーンがあると仮定します。
gdb <path-to-vmlinux> を実行 .list *(unwind_backtrace+0x10) .追加情報については、次のリソースを確認してください:
<オール><ブロック引用>
unwind_backtrace+0x0/0xf8 で 何 +0x0/0xf8
最初の数字 (+0x0 ) は 関数の先頭からのオフセット です (unwind_backtrace この場合）。 2 番目の数字 (0xf8 ) は 関数の全長 です .これら 2 つの情報が与えられた場合、障害が発生した場所について既に予感があれば、これで疑いを確認するのに十分かもしれません (機能のどこまで進んでいたかを (大まかに) 知ることができます)。
対応する命令の正確なソース行を取得するには (通常、直観よりも優れています)、addr2line を使用します。 または他の回答の他の方法。
これは単なる通常のバックトレースであり、これらの関数は逆の順序で呼び出されます (最初に呼び出された関数は前の関数によって呼び出されます):
unwind_backtrace+0x0/0xf8
warn_slowpath_common+0x50/0x60
warn_slowpath_null+0x1c/0x24
ocal_bh_enable_ip+0xa0/0xac
bdi_register+0xec/0x150
bdi_register+0xec/0x150 は、シンボル + オフセット/長さです。詳細については、カーネル Oop の理解とカーネル Oop のデバッグ方法を参照してください。また、カーネルのデバッグに関するこの優れたチュートリアルもあります
注:Eugene によって以下に提案されているように、最初に addr2line を試してみることをお勧めします。ただし、デバッグ シンボルを含むイメージが必要です。たとえば、
addr2line -e vmlinux_with_debug_info 0019594c(+offset)