2010-04-15 18 views
1

Je suis en train de déboguer ce qui semble être un problème de file d'attente d'achèvement:obtenir des lignes numéros de trace d'appel du noyau

Apr 14 18:39:15 ST2035 kernel: Call Trace: 
Apr 14 18:39:15 ST2035 kernel: [<ffffffff8049b295>] schedule_timeout+0x1e/0xad 
Apr 14 18:39:15 ST2035 kernel: [<ffffffff8049a81c>] wait_for_common+0xd5/0x13c 
Apr 14 18:39:15 ST2035 kernel: [<ffffffffa01ca32b>] 
ib_unregister_mad_agent+0x376/0x4c9 [ib_mad] 
Apr 14 18:39:16 ST2035 kernel: [<ffffffffa03058f4>] ib_umad_close+0xbd/0xfd 

Est-il possible de transformer ces nombres hexadécimaux en quelque chose proche de numéros de ligne?

+0

Avez-vous essayé de construire avec kalllsyms_all et bug verbeux()? – user2284570

Répondre

4

Pas exactement, mais si vous avez une image vmlinux construit avec informations de débogage, (par exemple, dans RHEL, vous devriez être en mesure d'installer le noyau-debug ou kernel-dbg ou quelque chose comme ça), vous pouvez approcher. Donc, en supposant que vous avez ce fichier vmlinux disponible. Effectuez les opérations suivantes:

objdump S vmlinux

Cela est plus difficile essayer de faire correspondre le code objet à certaines lignes de code source.

par exemple. pour le code C suivant:

#include <stdio.h> 
main() { 
    int a = 1; 
    int b = 2; 

    // This is a comment 

    printf("This is the print line %d\n", b); 
} 

compilé avec: cc -g test.c

puis de objdump -S sur l'exécutable résultant, j'obtenir un grand rendement décrivant les différentes parties de l'exécutable inclding la section suivante:

00000000004004cc <main>: 
#include <stdio.h> 
main() { 
    4004cc: 55      push %rbp 
    4004cd: 48 89 e5    mov %rsp,%rbp 
    4004d0: 48 83 ec 20    sub $0x20,%rsp 
    int a = 1; 
    4004d4: c7 45 f8 01 00 00 00 movl $0x1,-0x8(%rbp) 
    int b = 2; 
    4004db: c7 45 fc 02 00 00 00 movl $0x2,-0x4(%rbp) 

    // This is a comment 

    printf("This is the print line %d\n", b); 
    4004e2: 8b 75 fc    mov -0x4(%rbp),%esi 
    4004e5: bf ec 05 40 00   mov $0x4005ec,%edi 
    4004ea: b8 00 00 00 00   mov $0x0,%eax 
    4004ef: e8 cc fe ff ff   callq 4003c0 <[email protected]> 
} 

Vous pouvez faire correspondre les adresses du code objet dans la première colonne avec les adresses de votre trace de pile. Combinez cela avec le numéro de ligne info entrelacé dans la sortie d'assemblage ... et vous êtes là. Maintenant, gardez à l'esprit que cela ne réussira pas toujours à 100% parce que le kenrel est normalement compilé au niveau d'optimisation -O2 et le compilateur aurait fait beaucoup de ré-ordonnancement de code, etc. Mais si vous connaissez le code que vous essayez de déboguer et que vous ayez du réconfort pour déchiffrer l'assemblage de la plate-forme sur laquelle vous travaillez ... vous devriez être capable de localiser la plupart de vos plantages, etc.

+0

objdump! C'est la commande. Ça fait deux ans que je ne m'en souviens pas pour la vie de moi. J'ai fait un objdump sur le module avec le problème, j'ai obtenu quelques données utiles. Merci. –