Debug live del kernel Linux, come si fa e quali strumenti vengono utilizzati?

Un'altra opzione è utilizzare il controller ICE/JTAG e GDB. Questa soluzione "hardware" è particolarmente utilizzata con i sistemi embedded,

ma per esempio Qemu offre caratteristiche simili:

• avvia qemu con uno stub 'remote' gdb che ascolta su 'localhost:1234' :qemu -s ... ,

• quindi con GDB apri il file del kernel vmlinux compilato con informazioni di debug (puoi dare un'occhiata a questo thread della mailing list dove discutono della non ottimizzazione del kernel).

• collegare GDB e Qemu:target remote localhost:1234

• guarda il tuo dal vivo 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
  

sfortunatamente, il debug nello spazio utente non è finora possibile con GDB (nessuna informazione sull'elenco delle attività, nessuna riprogrammazione MMU per vedere diversi contesti di processo, ...), ma se rimani nello spazio del kernel, è abbastanza conveniente.

• info threads ti fornirà l'elenco e gli stati delle diverse CPU

MODIFICA:

Puoi ottenere maggiori dettagli sulla procedura in questo PDF:

Debug di sistemi Linux utilizzando GDB e QEMU.

Durante il debug del kernel Linux possiamo utilizzare diversi strumenti, ad esempio debugger (KDB, KGDB), dump durante l'arresto anomalo (LKCD), toolkit di tracciamento (LTT, LTTV, LTTng), strumenti del kernel personalizzati (dprobes, kprobes). Nella sezione seguente ho provato a riassumerne la maggior parte, spero che possano essere d'aiuto.

LKCD (Linux Kernel Crash Dump) permette al sistema Linux di scrivere il contenuto della sua memoria quando si verifica un crash. Questi registri possono essere ulteriormente analizzati per la causa principale dell'arresto anomalo. Risorse riguardanti 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

Spiacenti quando il kernel rileva un problema, stampa un messaggio Oops. Tale messaggio è generato dalle istruzioni printk nel gestore degli errori (arch/*/kernel/traps.c). Un ring buffer dedicato nel kernel utilizzato dalle istruzioni printk. Oops contiene informazioni come la CPU in cui si sono verificati gli Oops, il contenuto dei registri della CPU, il numero di Oops, la descrizione, la traccia dello stack e altro. Risorse relative al kernel Oops

• https://www.kernel.org/doc/Documentation/oops-tracing.txt
• http://madwifi-project.org/wiki/DevDocs/KernelOops
• https://wiki.ubuntu.com/DebuggingKernelOops

Sonde dinamiche è uno dei popolari strumenti di debug per Linux sviluppato da IBM. Questo strumento consente il posizionamento di una "sonda" in quasi tutti i punti del sistema, sia nello spazio dell'utente che in quello del kernel. La sonda è costituita da un codice (scritto in un linguaggio specializzato orientato allo stack) che viene eseguito quando il controllo raggiunge il punto specificato. Risorse relative a Dynamic Probe elencate di seguito

• 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 è una patch del kernel e un insieme di utilità correlate che consentono di tracciare gli eventi nel kernel. La traccia include informazioni sui tempi e può creare un quadro ragionevolmente completo di ciò che è accaduto in un determinato periodo di tempo. Risorse di LTT, LTT Viewer e 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 è uno strumento di rilevamento degli errori di memoria open source. Funziona definendo MEMWATCH nell'istruzione gcc e aggiungendo un file di intestazione al nostro codice. Attraverso questo possiamo tenere traccia delle perdite di memoria e dei danneggiamenti della memoria. Risorse riguardanti MEMWATCH

• http://www.linuxjournal.com/article/6059

ftrace è un buon framework di tracciamento per il kernel Linux. ftrace traccia le operazioni interne del kernel. Questo strumento è incluso nel kernel Linux in 2.6.27. Con i suoi vari plug-in tracer, ftrace può essere mirato a diversi tracepoint statici, come eventi di pianificazione, interruzioni, I/O mappati in memoria, transizioni dello stato di alimentazione della CPU e operazioni relative ai file system e alla virtualizzazione. Inoltre, è disponibile il tracciamento dinamico delle chiamate alle funzioni del kernel, opzionalmente restringibile a un sottoinsieme di funzioni utilizzando i glob e con la possibilità di generare grafici delle chiamate e fornire l'utilizzo dello stack. Puoi trovare un buon tutorial di ftrace su https://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_rostedt.pdf

lttrace è un'utilità di debug in Linux, utilizzata per visualizzare le chiamate che un'applicazione in spazio utente effettua alle librerie condivise. Questo strumento può essere utilizzato per tracciare qualsiasi chiamata di funzione di libreria dinamica. Intercetta e registra le chiamate alla libreria dinamica che vengono chiamate dal processo eseguito e i segnali che vengono ricevuti da quel processo. Può anche intercettare e stampare le chiamate di sistema eseguite dal programma.

• http://www.ellexus.com/getting-started-with-ltrace-how-does-it-do-that/?doing_wp_cron=1425295977.1327838897705078125000
• http://developerblog.redhat.com/2014/07/10/ltrace-for-rhel-6-and-7/

KBB è il debugger in-kernel del kernel Linux. KDB segue un'interfaccia semplicistica in stile shell. Possiamo usarlo per ispezionare memoria, registri, elenchi di processi, dmesg e persino impostare punti di interruzione per fermarsi in una determinata posizione. Tramite KDB possiamo impostare punti di interruzione ed eseguire alcuni controlli di esecuzione del kernel di base (Sebbene KDB non sia un debugger a livello di origine ). Diverse utili risorse riguardanti 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 è pensato per essere utilizzato come debugger a livello di sorgente per il kernel Linux. Viene utilizzato insieme a gdb per eseguire il debug di un kernel Linux. Per utilizzare kgdb sono necessarie due macchine. Una di queste macchine è una macchina di sviluppo e l'altra è la macchina di destinazione. Il kernel di cui eseguire il debug viene eseguito sulla macchina di destinazione. L'aspettativa è che gdb possa essere utilizzato per "irrompere" nel kernel per ispezionare memoria, variabili e esaminare le informazioni sullo stack di chiamate in modo simile al modo in cui uno sviluppatore di applicazioni utilizzerebbe gdb per eseguire il debug di un'applicazione. È possibile inserire punti di interruzione nel codice del kernel ed eseguire alcune fasi di esecuzione limitate. Diverse utili risorse su KGDB

• http://landley.net/kdocs/Documentation/DocBook/xhtml-nochunks/kgdb.html

Secondo il wiki, kgdb è stato unito al kernel in 2.6.26 che è negli ultimi anni. kgdb è un debugger remoto, quindi lo attivi nel tuo kernel e poi gli alleghi gdb in qualche modo. Dico in qualche modo perché sembra che ci siano molte opzioni - vedi collegamento di gdb. Dato che kgdb è ora nell'albero dei sorgenti, direi che in futuro questo è ciò che vorrai utilizzare.

Quindi sembra che Linus abbia ceduto. Tuttavia, vorrei sottolineare la sua argomentazione:dovresti sapere cosa stai facendo e conoscere bene il sistema. Questa è la terra dei chicchi. Se qualcosa va storto, non ottieni segfault , ottieni qualsiasi cosa da qualche oscuro problema in seguito all'intero sistema che scende. Ecco i draghi. Procedi con cautela, sei stato avvisato.