Scopo: Questo è un breve post in cui vedremo come look-up un nome simbolico (funzione o una variabile) dall'indirizzo che emesso nel kernel log dmesg e viceversa.

Nota: Si prega di notare che questo non è un HOWTO su come eseguire il debug del kernel Linux quando lo fa un OOPS o Kernel Panic. Può essere che mi occuperò di questi argomenti in una data successiva.

Diciamo che si aggiorna il kernel e si nota la seguente anomalia nei log dmesg anche se il sistema sembra avviarsi bene, almeno ad occhio nudo:

[ 24.155180] irq 17: nobody cared (try booting with the "irqpoll" option)
[ 24.155284] Pid: 0, comm: swapper Not tainted 2.6.32-bpo.5-686 #1
[ 24.155373] Call Trace:
[ 24.155463] [<c106cf75>] ? __report_bad_irq+0x24/0x69
[ 24.155554] [<c106cf7c>] ? __report_bad_irq+0x2b/0x69
[ 24.155644] [<c106d0a1>] ? note_interrupt+0xe7/0x13e
[ 24.155734] [<c106d5cf>] ? handle_fasteoi_irq+0x7a/0x97
[ 24.155827] [<c1004dd7>] ? handle_irq+0x17/0x1b
[ 24.155915] [<c1004659>] ? do_IRQ+0x38/0x89
[ 24.156002] [<c10037f0>] ? common_interrupt+0x30/0x38
[ 24.156096] [<c10400d8>] ? ftrace_raw_output_workqueue_insertion+0x80/0x8c
[ 24.156192] [<c104f06e>] ? tick_nohz_stop_sched_tick+0x34a/0x36e
[ 24.156285] [<c1002367>] ? cpu_idle+0x67/0xa4
[ 24.156375] [<c13bf7fc>] ? start_kernel+0x318/0x31d
[ 24.156461] handlers:
[ 24.156539] [<f7cc3855>] (usb_hcd_irq+0x0/0x71 [usbcore])
[ 24.156755] Disabling IRQ #17

Ora diciamo che si vuole capire che cosa i mezzi di output altamente tecnici di cui sopra. Pickup Facciamo una linea dal di sopra fuori dire quello nel colore rosso e si assume che questa linea ci potrebbe dare informazioni utili per quanto riguarda l'anomalia di cui sopra, anche se questo potrebbe non essere il caso, perché in un effettivo oops, è in genere il primo o l'ultima riga nel backtrace che ha fornito le informazioni di debug più utili. Cerchiamo di capire uno ad uno ciò che ciascuno di tali colonne nella riga seguente significa:

? handle_irq + 0×17 / 0x1b [24.155827] [<c1004dd7>]? Handle_irq + 0 × 17 / 0x1b

[24.155827] sono le informazioni timestamp stampati dal kernel di Linux. Questo significa semplicemente che questa linea era uscita di circa 24 secondi più tardi dopo che il kernel Linux ha iniziato il boot.

, in the System Map table. [<c1004dd7>] È l'indirizzo (diciamo solo per ora) della funzione, handle_irq, nella mappa del sistema tavolo.

handle_irq è il nome della funzione "incriminata" nel codice del kernel di Linux.

0 × 17 è l'offset che indica sostanzialmente fuori il pezzo di codice nella funzione che è stato coinvolto nella azione di cui sopra (e non il numero di riga).

. 0x1b è dimensione della funzione, handle_irq. ). L'offset (0 × 17) deve sempre essere inferiore alla dimensione della funzione (0x1b).

Ora vediamo come queste informazioni relative al file di tabella Map System che viene generato quando si installa il kernel di Linux.

Dare il seguente comando:

# cat /boot/System.map-2.6.32-bpo.5-686 | grep handle_irq

Sarà necessario sostituire il nome del file della tabella Mappa del kernel di sistema di conseguenza.

Uscita:

c1004dc0 T handle_irq
c100cffc t intel_pmu_handle_irq
c100d2a4 t p6_pmu_handle_irq
c100d3bd t amd_pmu_handle_irq

Siamo interessati in prima linea dal momento che è quello che pensiamo che la nostra funzione incriminata è. that we found in the output above. Tuttavia, l'indirizzo c1004dc0 non corrisponda con l'indirizzo (c1004dd7) che abbiamo trovato in uscita di cui sopra. Quindi, come possiamo conciliare questi numeri?

ie Proviamo a sottrarre il numero esadecimale c1004dc0 da c1004dd7 ie

c1004dd7 - c1004dc0 = 17

Bingo! Il numero 17 partite con l'uscita, 0 × 17, che abbiamo ottenuto in anomalia. Quindi, per riassumere:

. c1004dc0 è l'indirizzo iniziale della funzione handle_irq.

c1004dd7 è l'indirizzo (dopo aver aggiunto 17 all'indirizzo di partenza sopra) del pezzo di codice nella funzione.

Allo stesso modo, si può fare questi esercizi per altre funzioni come cpu_idle e start_kernel dal dmesg sopra.

Questo è tutto!

Be Sociable, Share!

Altri Related Posts: