Debuggen des Linux-Kernels mit QEMU

Abhängig von der Distribution, die Sie verwenden möchten, gibt es verschiedene Möglichkeiten, ein Dateisystem-Image zu erstellen, z. Dieser Artikel führt Sie durch den mühsamen Weg zu einem "Linux from Scratch" System.

Allgemein , würden Sie beides Erstellen Sie ein QEMU-Image mit qemu-img , holen Sie sich das Installationsmedium einer Distribution und verwenden Sie QEMU mit dem Installationsmedium, um das Image vorzubereiten (diese Seite erklärt den Prozess für Debian GNU/Linux) oder Verwenden Sie ein von jemand anderem erstelltes Bild.

Dieser Abschnitt des QEMU-Wikibooks enthält alle Informationen, die Sie benötigen.

Bearbeiten: Wie die Antwort von Gilles auf die verknüpfte Frage andeutet, benötigen Sie zum Testen kein vollständiges Root-Dateisystem, Sie könnten einfach eine initrd verwenden image (z. B. die initrd von Arch Linux wie hier)

QEMU + GDB Schritt-für-Schritt-Verfahren auf Ubuntu 16.10-Host getestet

Um schnell von Grund auf neu anzufangen, habe ich ein minimales vollautomatisiertes QEMU + Buildroot-Beispiel erstellt unter:https://github.com/cirosantilli/linux-kernel-module-cheat. Die wichtigsten Schritte werden unten behandelt.

Holen Sie sich zuerst ein Root-Dateisystem rootfs.cpio.gz . Wenn Sie eine benötigen, ziehen Sie Folgendes in Betracht:

• mindestens init -nur ausführbares Image:Benutzerdefinierte Linux-Distribution, die nur ein Programm ausführt, sonst nichts | Unix- und Linux-Stack-Austausch
• ein interaktives Busybox-System:Was ist die kleinstmögliche Linux-Implementierung? | Unix- und Linux-Stack-Austausch

Dann auf dem Linux-Kernel:

git checkout v4.9
make mrproper
make x86_64_defconfig
cat <<EOF >.config-fragment
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_GDB_SCRIPTS=y
EOF
./scripts/kconfig/merge_config.sh .config .config-fragment
make -j"$(nproc)"
qemu-system-x86_64 -kernel arch/x86/boot/bzImage \
                   -initrd rootfs.cpio.gz -S -s

Angenommen, Sie möchten auf einem anderen Terminal mit dem Debuggen ab start_kernel beginnen :

gdb \
    -ex "add-auto-load-safe-path $(pwd)" \
    -ex "file vmlinux" \
    -ex 'set arch i386:x86-64:intel' \
    -ex 'target remote localhost:1234' \
    -ex 'break start_kernel' \
    -ex 'continue' \
    -ex 'disconnect' \
    -ex 'set arch i386:x86-64' \
    -ex 'target remote localhost:1234'

und wir sind fertig!!

Für Kernel-Module siehe:Wie debuggt man Linux-Kernel-Module mit QEMU? | Stapelüberlauf

Für Ubuntu 14.04, GDB 7.7.1, hbreak wurde benötigt, break Software-Haltepunkte wurden ignoriert. In 16.10 nicht mehr der Fall. Siehe auch:https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/901944

Die chaotische disconnect und was danach kommt, um den Fehler zu umgehen:

Remote 'g' packet reply is too long: 000000000000000017d11000008ef4810120008000000000fdfb8b07000000000d352828000000004040010000000000903fe081ffffffff883fe081ffffffff00000000000e0000ffffffffffe0ffffffffffff07ffffffffffffffff9fffff17d11000008ef4810000000000800000fffffffff8ffffffffff0000ffffffff2ddbf481ffffffff4600000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000

Verwandte Threads:

• https://sourceware.org/bugzilla/show_bug.cgi?id=13984 könnte ein GDB-Fehler sein
• gdb - Remote-'g'-Paketantwort ist zu lang | Stapelüberlauf
• http://wiki.osdev.org/QEMU_and_GDB_in_long_mode osdev.org ist wie immer eine großartige Quelle für diese Probleme
• https://lists.nongnu.org/archive/html/qemu-discuss/2014-10/msg00069.html

Siehe auch:

• https://github.com/torvalds/linux/blob/v4.9/Documentation/dev-tools/gdb-kernel-debugging.rst offizielle Linux-Kernel-"Dokumentation"
• Wie debuggt man den Linux-Kernel mit GDB und QEMU? | Stapelüberlauf

Bekannte Einschränkungen:

• der Linux-Kernel unterstützt nicht (und lässt sich nicht einmal ohne Patches kompilieren) mit -O0 :Wie deoptimiere ich den Linux-Kernel und kompiliere ihn mit -O0? | Stapelüberlauf
• GDB 7.11 wird Ihr Gedächtnis bei einigen Arten der Tab-Vervollständigung sprengen, selbst nach max-completions fix:Unterbrechung der Tab-Vervollständigung für große Binärdateien | Stapelüberlauf Wahrscheinlich ein Sonderfall, der in diesem Patch nicht behandelt wurde. Also eine ulimit -Sv 500000 ist eine kluge Aktion vor dem Debuggen. Ist speziell explodiert, als ich mit der Tabulatortaste file<tab> abgeschlossen habe für filename Argument von sys_execve wie in:Kann der Systemaufruf sys_execve() im Linux-Kernel sowohl absolute als auch relative Pfade erhalten? | Stapelüberlauf