Wie debugge ich den Linux Kernel mit GDB und QEMU?

Ich bin neu in die kernel-Entwicklung, und ich würde gerne wissen, wie Sie die run/debug-linux-kernel mit QEMU und gdb. Ich bin eigentlich Lesen von Robert Love ist das Buch aber leider ist es nicht dem Leser helfen, wie zu installieren, die richtigen Werkzeuge zum ausführen oder Debuggen der kernel... Also, was ich Tat, war, Folgen Sie diesem tutorial http://opensourceforu.efytimes.com/2011/02/kernel-development-debugging-using-eclipse/. Ich bin mit eclipse als IDE zu entwickeln, die auf den kernel, aber Erstens wollte ich, um es arbeiten unter QEMU/gdb. So was habe ich bisher war:

1) Zum kompilieren des Kernels mit:

make defconfig (then setting the CONFIG_DEBUG_INFO=y in the .config)
make -j4

2) Sobald die Kompilierung ist vorbei ich Qemu gestartet mit:

qemu-system-x86_64 -s -S /dev/zero -kernel /arch/x86/boot/bzImage

dem starten des kernel in "stopped" state

3) So habe ich den Gebrauch von gdb, ich versuche folgenden Befehl:

gdb ./vmlinux

welche läuft es richtig, aber... Nun, ich weiß nicht, was zu tun ist... ich weiß, dass ich für die Verwendung von remote-debugging auf dem port 1234 (Standard-port verwendet, der von Qemu), mit dem vmlinux als symbol table file für die Fehlersuche.

Also meine Frage ist: Was muss ich tun, um führen Sie den kernel auf Qemu, befestigen, mein debugger und wird somit bekommen Sie zusammen arbeiten, um mein Leben einfacher mit der kernel-Entwicklung.

InformationsquelleAutor der Frage E-Kami | 2012-07-10

  1. 23

    Ich würde versuchen:

    (gdb) target remote localhost:1234
(gdb) continue

    Verwendung der '-s' option macht qemu hört auf port tcp::1234, können Sie eine Verbindung zu localhost:1234 wenn Sie sich auf der gleichen Maschine. Qemu-s '-S' option macht Qemu beenden Sie die Ausführung, bis Sie die continue-Befehl.

    Beste würde wahrscheinlich sein, einen Blick auf eine anständige GDB tutorial zu bekommen, zusammen mit dem, was Sie tun. Diese eine sieht ganz nett aus.

    InformationsquelleAutor der Antwort BjoernD

  2. 15

    Schritt-für-Schritt-Verfahren getestet auf Ubuntu 16.10 host

    Einstieg von Grund auf schnell habe ich eine minimale Vollautomatische QEMU + Buildroot Beispiel: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/c7bbc6029af7f4fab0a23a380d1607df0b2a3701/gdb-step-debugging.md Großen Schritte, die nachfolgend vorgestellt werden.

    Zuerst ein root-Dateisystem rootfs.cpio.gz. Wenn Sie einen brauchen, die Sie berücksichtigen sollten:

    Dann auf dem Linux-kernel:

    git checkout v4.15
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 \
                   -append nokaslr

    Auf einem anderen terminal, aus dem inneren des Linux-kernel-tree, angenommen, dass Sie möchten, starten Sie das Debuggen von start_kernel:

    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 finden Sie unter: Gewusst wie: Debuggen von Linux-kernel-Module mit QEMU?

    Für Ubuntu 14.04, GDB 7.7.1, hbreak nötig war, break software-breakpoints ignoriert wurden. Nicht mehr der Fall in 16.10. Siehe auch: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/901944

    Chaotisch disconnect und was nach ihm kommen werden, um Fehler zu umgehen:

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

    Verwandte threads:

    Bekannte Einschränkungen:

    Siehe auch:

    InformationsquelleAutor der Antwort Ciro Santilli 新疆改造中心 六四事件 法轮功

  3. 3

    BjoernID die Antwort nicht wirklich Arbeit für mich. Nachdem die erste Fortsetzung, kein breakpoint erreicht ist und auf einen interrupt, ich würde sehen, Zeilen wie:

    0x0000000000000000 in ?? ()
(gdb) break rapl_pmu_init
Breakpoint 1 at 0xffffffff816631e7
(gdb) c
Continuing.
^CRemote 'g' packet reply is too long: 08793000000000002988d582000000002019[..]

    Ich denke, das hat etwas zu tun mit verschiedenen CPU-Modi (real-Modus im BIOS-vs. long-Modus, wenn Linux gebootet wurde). Ja eh, die Lösung ist um QEMU laufen lassen, zuerst, ohne zu warten (d.h. ohne -S):

    qemu-system-x86_64 -enable-kvm -kernel arch/x86/boot/bzImage -cpu SandyBridge -s

    In meinem Fall, ich musste brechen etwas beim Booten, also nach einigen deciseconds, lief ich den gdb-Befehl. Wenn Sie mehr Zeit haben (z.B. müssen Sie eine debug-Modul, das geladen wird, manuell), dann das timing nicht wirklich wichtig.

    gdb können Sie Befehle angeben, die ausgeführt werden soll, wenn Sie gestartet werden. Dies macht die Automatisierung ein bisschen einfacher. Die Verbindung zu QEMU (das sollte nun bereits gestartet sein), brechen auf eine Funktion und fortsetzen der Ausführung, Verwendung:

    gdb -ex 'target remote localhost:1234' -ex 'break rapl_pmu_init' -ex c ./vmlinux

    InformationsquelleAutor der Antwort Lekensteyn

  4. 2

    Wenn Sie versuchen, starten Sie die exe-Datei vmlinux mit gdb, dann erste, was gdb ist zu erteilen Befehle:

    (gdb) target remote localhost:1234

    (gdb) break start_kernel

    (weiter)

    Diese brechen mit dem kernel start_kernel.

    InformationsquelleAutor der Antwort Ritesh

  5. 1

    Als für mich die beste Lösung für das Debuggen des Kernels -, ist die Verwendung von gdb aus Eclipse-Umgebung. Sie sollten nur die entsprechenden port für den gdb (muss identisch sein mit einer von Ihnen bestimmten qemu starten, string) in das remote-debugging-Abschnitt. Hier ist die Anleitung:
    http://www.sw-at.com/blog/2011/02/11/linux-kernel-development-and-debugging-using-eclipse-cdt/

    InformationsquelleAutor der Antwort Alex Hoppus

Schreibe einen Kommentar