Propósito: Este es un breve post en el que vamos a ver la forma de ver de un nombre de símbolo (función o una variable) de la dirección que se emite en los registros de dmesg kernel y viceversa.

Nota: Tenga en cuenta que esto no es un HOWTO sobre cómo depurar Linux Kernel cuando lo hace un OOPS o Kernel Panic. Puede ser voy a cubrir esos temas en una fecha posterior.

Digamos que actualice su núcleo y se nota la siguiente anomalía en los registros de dmesg, aunque su sistema parece arrancar bien, al menos a simple vista:

[ 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

Ahora digamos que usted quiere entender lo que hace a los medios de salida muy técnicas anteriores. Vamos a capturar una línea de lo anterior decir en el que está en el color rojo y suponemos que esta línea nos puede dar información útil sobre la anomalía anterior, aunque esto podría no ser el caso, ya que en una real perdón, por lo general es la primera o la última línea de la traza que proporcionó la información de depuración más útil. Vamos a entender uno por uno lo que cada una de esas columnas en la siguiente línea significa:

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

[24.155827] es la información de marcas de tiempo impreso por el Kernel de Linux. Esto simplemente significa que esta línea fue la salida de aproximadamente 24 segundos más tarde después de que el kernel de Linux inicia el arranque.

, in the System Map table. [<C1004dd7>] es la dirección (digamos que por ahora) de la función, handle_irq, en el mapa de sistema de mesa.

handle_irq es el nombre de la función de "ofender" en el código del kernel de Linux.

0x17 es el desplazamiento (y no el número de línea) que básicamente apunta a la pieza del código en la función que estuvo involucrado en la acción anterior.

. 0x1b es el tamaño de la función, handle_irq. ). El desplazamiento (0x17) siempre debe ser menor que el tamaño de la función (0x1b).

Ahora vamos a ver cómo esta información relacionada con el archivo de tabla de mapa de sistema que se genera al instalar el kernel de Linux.

Dé el siguiente comando:

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

Tendrá que sustituir el nombre de su archivo de tabla Kernel Mapa del sistema en consecuencia.

Salida:

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

Estamos interesados ​​en la primera línea, ya que es lo que creemos que nuestra función es ofender. that we found in the output above. Sin embargo, el c1004dc0 dirección no coincide con la dirección (c1004dd7) que encontramos en la salida anterior. Entonces, ¿cómo podemos reconciliar estos números?

ie Vamos a tratar de restar el número hexadecimal c1004dc0 de c1004dd7 es decir,

c1004dd7 - c1004dc0 = 17

¡Bingo! El número 17 partidos con la salida, 0x17, que nos dieron en la anomalía. Entonces, para resumir:

. c1004dc0 es la dirección inicial de la handle_irq función.

c1004dd7 es la dirección (después de añadir 17 a la dirección de partida arriba) de la pieza del código de la función.

Del mismo modo, puede hacer estos ejercicios para otras funciones como cpu_idle y start_kernel desde la salida de dmesg arriba.

Eso es todo!

Be Sociable, Share!