Comment lire, comprendre, analyser et déboguer une panique du noyau Linux ?

Voici deux alternatives pour addr2line . En supposant que vous disposiez de la chaîne d'outils de la cible appropriée, vous pouvez effectuer l'une des actions suivantes :

Utilisez objdump :

1. localisez votre vmlinux ou le .ko sous le répertoire racine du noyau, puis désassemblez le fichier objet :

   objdump -dS vmlinux > /tmp/kernel.s
   

2. Ouvrez le fichier d'assemblage généré, /tmp/kernel.s . avec un éditeur de texte tel que vim . Aller àunwind_backtrace+0x0/0xf8 , c'est-à-dire rechercher l'adresse de unwind_backtrace + le offset . Enfin, vous avez localisé la partie problématique dans votre code source.

Utilisez gdb :

IMO, une option encore plus élégante consiste à utiliser le seul et unique gdb . En supposant que vous disposiez de la chaîne d'outils appropriée sur votre ordinateur hôte :

1. Exécutez gdb <path-to-vmlinux> .
2. Exécuter dans l'invite de gdb :list *(unwind_backtrace+0x10) .

Pour plus d'informations, vous pouvez consulter les ressources suivantes :

1. Astuces de débogage du noyau.
2. Débogage du noyau Linux à l'aide de Gdb

En unwind_backtrace+0x0/0xf8 ce que le +0x0/0xf8 signifie ?

Le premier chiffre (+0x0 ) est le décalage depuis le début de la fonction (unwind_backtrace dans ce cas). Le deuxième nombre (0xf8 ) est la longueur totale de la fonction . Compte tenu de ces deux informations, si vous avez déjà une idée de l'endroit où la panne s'est produite, cela pourrait suffire à confirmer vos soupçons (vous pouvez dire (à peu près) où vous en étiez dans la fonction).

Pour obtenir la ligne source exacte de l'instruction correspondante (généralement mieux que les intuitions), utilisez addr2line ou les autres méthodes dans d'autres réponses.

C'est juste une trace ordinaire, ces fonctions sont appelées dans l'ordre inverse (la première appelée a été appelée par la précédente et ainsi de suite) :

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

Le bdi_register+0xec/0x150 est le symbole + le décalage/longueur il y a plus d'informations à ce sujet dans Comprendre un problème de noyau et comment vous pouvez déboguer un problème de noyau. Il y a aussi cet excellent tutoriel sur le débogage du noyau

Remarque :comme suggéré ci-dessous par Eugene, vous pouvez d'abord essayer addr2line, mais il a toujours besoin d'une image avec des symboles de débogage, par exemple

addr2line -e vmlinux_with_debug_info 0019594c(+offset)