Eine weitere Option ist die Verwendung von ICE/JTAG-Controller und GDB. Diese 'Hardware'-Lösung wird besonders bei eingebetteten Systemen verwendet,
aber zum Beispiel bietet Qemu ähnliche Funktionen:
-
Starten Sie qemu mit einem gdb 'remote' Stub, der auf 'localhost:1234' lauscht:
qemu -s ..., -
dann öffnen Sie mit GDB die Kerneldatei
vmlinuxkompiliert mit Debug-Informationen (Sie können einen Blick in diesen Mailinglisten-Thread werfen, wo sie die Nicht-Optimierung des Kernels diskutieren). -
GDB und Qemu verbinden:
target remote localhost:1234 -
Sehen Sie sich Ihr Live an Kernel:
(gdb) where #0 cpu_v7_do_idle () at arch/arm/mm/proc-v7.S:77 #1 0xc0029728 in arch_idle () atarm/mach-realview/include/mach/system.h:36 #2 default_idle () at arm/kernel/process.c:166 #3 0xc00298a8 in cpu_idle () at arch/arm/kernel/process.c:199 #4 0xc00089c0 in start_kernel () at init/main.c:713
Leider ist User-Space-Debugging bisher mit GDB nicht möglich (keine Tasklisten-Informationen, keine MMU-Umprogrammierung, um unterschiedliche Prozesskontexte zu sehen, ...), aber wenn Sie im Kernel-Space bleiben, ist das recht praktisch.
info threadsgibt Ihnen die Liste und Zustände der verschiedenen CPUs
BEARBEITEN:
Weitere Einzelheiten zum Verfahren finden Sie in diesem PDF:
Debuggen von Linux-Systemen mit GDB und QEMU.
Beim Debuggen des Linux-Kernels können wir verschiedene Tools verwenden, zum Beispiel Debugger (KDB, KGDB), Dumping während eines Absturzes (LKCD), Tracing-Toolkit (LTT, LTTV, LTTng), benutzerdefinierte Kernel-Instrumente (dprobes, kprobes). Im folgenden Abschnitt habe ich versucht, die meisten davon zusammenzufassen, ich hoffe, diese helfen.
LKCD (Linux Kernel Crash Dump)-Tool ermöglicht es dem Linux-System, den Inhalt seines Speichers zu schreiben, wenn ein Absturz auftritt. Diese Protokolle können weiter auf die Grundursache des Absturzes analysiert werden. Ressourcen zu LKCD
- http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaax/lkcd.pdf
- https://www.novell.com/coolsolutions/feature/15284.html
- https://www.novell.com/support/kb/doc.php?id=3044267
Ups Wenn der Kernel ein Problem erkennt, gibt er eine Oops-Meldung aus. Eine solche Nachricht wird durch printk-Anweisungen im Fault-Handler (arch/*/kernel/traps.c) generiert. Ein dedizierter Ringpuffer im Kernel, der von den printk-Anweisungen verwendet wird. Oops enthält Informationen wie die CPU, auf der die Oops aufgetreten sind, Inhalte der CPU-Register, Anzahl der Oops, Beschreibung, Stackback-Trace und andere. Ressourcen zu Kernel-Oops
- https://www.kernel.org/doc/Documentation/oops-tracing.txt
- http://madwifi-project.org/wiki/DevDocs/KernelOops
- https://wiki.ubuntu.com/DebuggingKernelOops
Dynamische Sonden ist eines der beliebtesten Debugging-Tools für Linux, das von IBM entwickelt wurde. Dieses Tool ermöglicht die Platzierung einer „Sonde“ an fast jeder Stelle im System, sowohl im Benutzer- als auch im Kernel-Bereich. Die Sonde besteht aus einem Code (geschrieben in einer spezialisierten, stapelorientierten Sprache), der ausgeführt wird, wenn die Steuerung den angegebenen Punkt erreicht. Unten aufgeführte Ressourcen zu Dynamic Probe
- http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaax/dprobesltt.pdf
- http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.107.6212&rep=rep1&type=pdf
Linux Trace Toolkit ist ein Kernel-Patch und eine Reihe verwandter Dienstprogramme, die das Verfolgen von Ereignissen im Kernel ermöglichen. Die Ablaufverfolgung enthält Zeitinformationen und kann ein einigermaßen vollständiges Bild davon erstellen, was über einen bestimmten Zeitraum passiert ist. Ressourcen von LTT, LTT Viewer und LTT Next Generation
- http://elinux.org/Linux_Trace_Toolkit
- http://www.linuxjournal.com/article/3829
- http://multivax.blogspot.com/2010/11/introduction-to-linux-tracing-toolkit.html
MEMWATCH ist ein Open-Source-Tool zur Erkennung von Speicherfehlern. Es funktioniert, indem MEMWATCH in der gcc-Anweisung definiert und unserem Code eine Header-Datei hinzugefügt wird. Dadurch können wir Speicherlecks und Speicherbeschädigungen verfolgen. Ressourcen zu MEMWATCH
- http://www.linuxjournal.com/article/6059
ftrace ist ein gutes Tracing-Framework für den Linux-Kernel. ftrace verfolgt interne Operationen des Kernels. Dieses Tool ist in 2.6.27 im Linux-Kernel enthalten. Mit seinen verschiedenen Tracer-Plugins kann ftrace auf verschiedene statische Tracepoints abzielen, wie z. B. Scheduling-Ereignisse, Interrupts, speicherabgebildete E/A, CPU-Energiezustandsübergänge und Operationen im Zusammenhang mit Dateisystemen und Virtualisierung. Außerdem ist dynamisches Tracking von Kernel-Funktionsaufrufen verfügbar, optional beschränkbar auf eine Teilmenge von Funktionen durch Verwendung von Globs und mit der Möglichkeit, Aufrufgraphen zu generieren und Stack-Nutzung bereitzustellen. Eine gute Anleitung zu ftrace finden Sie unter https://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_rostedt.pdf
ltrace ist ein Debugging-Dienstprogramm in Linux, das verwendet wird, um die Aufrufe anzuzeigen, die eine Benutzerbereichsanwendung an gemeinsam genutzte Bibliotheken durchführt. Dieses Tool kann verwendet werden, um jeden Funktionsaufruf einer dynamischen Bibliothek zu verfolgen. Es fängt die dynamischen Bibliotheksaufrufe, die von dem ausgeführten Prozess aufgerufen werden, und die Signale, die von diesem Prozess empfangen werden, ab und zeichnet sie auf. Es kann auch die vom Programm ausgeführten Systemaufrufe abfangen und drucken.
- http://www.ellexus.com/getting-started-with-ltrace-wie-macht-es-das/?doing_wp_cron=1425295977.1327838897705078125000
- http://developerblog.redhat.com/2014/07/10/ltrace-for-rhel-6-and-7/
KDB ist der In-Kernel-Debugger des Linux-Kernels. KDB folgt einer vereinfachten Oberfläche im Shell-Stil. Wir können es verwenden, um Speicher, Register, Prozesslisten, dmesg zu inspizieren und sogar Haltepunkte zu setzen, um an einer bestimmten Stelle anzuhalten. Über KDB können wir Haltepunkte setzen und einige grundlegende Kernel-Laufsteuerungen ausführen (Obwohl KDB kein Source-Level-Debugger ist ). Mehrere praktische Ressourcen zu KDB
- http://www.drdobbs.com/open-source/linux-kernel-debugging/184406318
- http://elinux.org/KDB
- http://dev.man-online.org/man1/kdb/
- https://www.kernel.org/pub/linux/kernel/people/jwessel/kdb/usingKDB.html
KGDB soll als Source-Level-Debugger für den Linux-Kernel verwendet werden. Es wird zusammen mit gdb verwendet, um einen Linux-Kernel zu debuggen. Für die Verwendung von kgdb sind zwei Maschinen erforderlich. Eine dieser Maschinen ist eine Entwicklungsmaschine und die andere die Zielmaschine. Der zu debuggende Kernel wird auf der Zielmaschine ausgeführt. Die Erwartung ist, dass gdb verwendet werden kann, um in den Kernel "einzubrechen", um Speicher und Variablen zu inspizieren und Call-Stack-Informationen zu durchsuchen, ähnlich wie ein Anwendungsentwickler gdb verwenden würde, um eine Anwendung zu debuggen. Es ist möglich, Haltepunkte im Kernel-Code zu platzieren und einige eingeschränkte Ausführungsschritte durchzuführen. Mehrere praktische Ressourcen zu KGDB
- http://landley.net/kdocs/Documentation/DocBook/xhtml-nochunks/kgdb.html
Laut Wiki kgdb wurde in 2.6.26 in den Kernel eingebunden das ist in den letzten Jahren. kgdb ist ein Remote-Debugger, also aktivieren Sie ihn in Ihrem Kernel und hängen gdb irgendwie daran an. Ich sage irgendwie, da es viele Optionen zu geben scheint - siehe gdb verbinden. Da kgdb jetzt im Quellbaum befindet, würde ich sagen, dass Sie dies in Zukunft verwenden möchten.
Es sieht also so aus, als hätte Linus nachgegeben. Ich möchte jedoch seine Argumentation betonen - Sie sollten wissen, was Sie tun, und das System gut kennen. Das ist Kernland. Wenn etwas schief geht, erhalten Sie nicht segfault , erhalten Sie alles von einem obskuren Problem später bis zum Ausfall des gesamten Systems. Hier seien Drachen. Gehen Sie vorsichtig vor, Sie wurden gewarnt.