Come leggere, comprendere, analizzare ed eseguire il debug di un kernel panic di Linux?

Ecco due alternative per addr2line . Supponendo che tu abbia la toolchain del bersaglio corretta, puoi eseguire una delle seguenti operazioni:

Usa objdump :

1. individua il tuo vmlinux o il .ko file nella directory radice del kernel, quindi disassemblare il file oggetto :

   objdump -dS vmlinux > /tmp/kernel.s
   

2. Apri il file di assieme generato, /tmp/kernel.s . con un editor di testo come vim . Vai a unwind_backtrace+0x0/0xf8 , ovvero cerca l'indirizzo di unwind_backtrace + offset . Infine, hai individuato la parte problematica nel tuo codice sorgente.

Usa gdb :

IMO, un'opzione ancora più elegante è usare l'unico gdb . Supponendo che tu abbia la toolchain adatta sul tuo computer host:

1. Esegui gdb <path-to-vmlinux> .
2. Esegui nel prompt di gdb:list *(unwind_backtrace+0x10) .

Per ulteriori informazioni, puoi consultare le seguenti risorse:

1. Trucchi per il debug del kernel.
2. Debug del kernel Linux utilizzando Gdb

In unwind_backtrace+0x0/0xf8 cosa il +0x0/0xf8 sta per?

Il primo numero (+0x0 ) è l'offset dall'inizio della funzione (unwind_backtrace in questo caso). Il secondo numero (0xf8 ) è la lunghezza totale della funzione . Date queste due informazioni, se hai già un'idea di dove si è verificato l'errore, questo potrebbe essere sufficiente per confermare il tuo sospetto (puoi dire (approssimativamente) a che punto eri nella funzione).

Per ottenere l'esatta riga sorgente dell'istruzione corrispondente (generalmente meglio di humches), usa addr2line o gli altri metodi in altre risposte.

È solo un normale backtrace, quelle funzioni sono chiamate in ordine inverso (la prima chiamata è stata chiamata dalla precedente e così via):

unwind_backtrace+0x0/0xf8
warn_slowpath_common+0x50/0x60
warn_slowpath_null+0x1c/0x24
ocal_bh_enable_ip+0xa0/0xac
bdi_register+0xec/0x150

Il bdi_register+0xec/0x150 è il simbolo + l'offset/lunghezza ci sono maggiori informazioni a riguardo in Comprendere un kernel Oops e come puoi eseguire il debug di un kernel oops. Inoltre c'è questo eccellente tutorial sul debug del kernel

Nota:come suggerito di seguito da Eugene, potresti provare prima addr2line, ha comunque bisogno di un'immagine con simboli di debug, ad esempio

addr2line -e vmlinux_with_debug_info 0019594c(+offset)