2

物理メモリ ダンプ ファイルとシンボル ファイル (vmlinux) があり、ダンプ ファイルの内容を gdb のシンボル ファイルで分析したいと考えています。たとえば、物理メモリがダンプされた時点での init_task の状態を確認するには、次のようにします。

(gdb) print &init_task
=> show the address of init_task in physical memory dump file, said 0xc0XXXXXX

(gdb) print ((struct task_struct *) 0xc0XXXXXX)->tasks
=> show the content of init_task.tasks in physical memory dump file)

gdb コマンド「restore」と「target core」を試しましたが、どちらも機能しません。「復元」は実行中のプロセスで使用する必要があり、「ターゲット コア」は入力としてコア ファイル (ELF 64 ビット LSB コア ファイル) に必要です。

(gdb) restore binary physical-memory-dump-file
You can't do that without a process to debug.

(gdb) target core physical-memory-dump-file
"physical-memory-dump-file" is not a core dump: File format not recognized

何か案が？ありがとう。

Update1: こんにちは Pavan さん、思い出させてくれてありがとう。私は特別なプラットフォームで作業しているため、パニック/おっとからカーネルを再起動した後、そのプラットフォームのブートローダーは完全な物理メモリをダンプ ファイルに保存します。したがって、physical-memory-dump-file は物理 RAM と同じサイズになり、最初のバイトからカーネルの 0xc000:0000 にマップできます。

4

1 に答える 1

2

物理メモリダンプとコアファイルはまったく同じものではありません。コアファイルは、アドレス空間にマップされた単なる実行可能イメージです。カーネルがパニックになると、ELFファイルをメモリ内のある位置に残し、ハードコードされたアドレスがイメージの他の部分を指すようにする必要があります。GDBがELFイメージを受け入れて、持っているシンボルと一致させる前に、持っているメモリダンプからELFイメージを抽出する（未使用の部分を取り除く）必要がある可能性があります。

于 2012-04-06T04:21:54.317 に答える