gdb - debugging kernel mit physischer speicher dump datei

Question

Ich habe eine physische speicher dump-datei und eine symbol-datei (vmlinux), und ich möchte den inhalt der dump-datei mit symbol datei in gdb analysieren. Zum Beispiel kann der physikalische Speicher entleert den Zustand init_task spähen damals:

(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) 

Ich habe gerade versucht die GDB-Befehle „wiederherstellen“ und „Ziel Kern“, sind beide nicht funktionieren. "restore" muss für einen laufenden Prozess verwendet werden, und "target core" muss in der Kerndatei (ELF 64-bit LSB core file) als Eingabe verwendet werden.

(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 

Irgendeine Idee? Vielen Dank.

Update1: Hallo Pavan, danke für die Erinnerung; Da ich auf einer speziellen Plattform arbeite, speichert der Bootloader darauf den vollständigen physischen Speicher in der Dump-Datei, nach dem Kernel-Neustart von Panik/Hoppla. Daher wird die physische Speicherauszugsdatei dieselbe Größe mit physischem RAM haben, und es kann dem 0xc000: 0000 im Kernel vom ersten Byte davon zugeordnet werden.

Answer 1

Ein physischer Speicherabzug und eine Kerndatei sind nicht genau dasselbe. Eine Kerndatei ist nur ein ausführbares Bild, das in einen Adressraum abgebildet wird; Wenn der Kernel in Panik gerät, sollte er eine ELF-Datei an einer bestimmten Stelle im Speicher belassen, mit fest codierten Adressen, die auf andere Teile des Bildes zeigen. Es ist wahrscheinlich, dass Sie das ELF-Image aus dem Speicherauszug extrahieren müssen (die nicht verwendeten Teile entfernen), bevor GDB es akzeptiert und die Symbole, die Sie haben, abgleicht.