J'ai configurer tous les config_debug _ code> options associées à
y code>, mais quand j'essaie de déboguer le noyau, il n'est pas indiqué aucun symbole de débogage trouvé:
gdb /usr/src/linux-2.6.32.9/vmlinux /proc/kcore
Reading symbols from /usr/src/linux-2.6.32.9/vmlinux...(no debugging symbols found)...done.
5 Réponses :
Je me tromperai peut-être, mais je pensais que vous devriez installer le paquet debuginfo pour votre noyau pour obtenir des symboles p>
Non, je pense avoir déjà installé ce paquet: config_debug_info = y code>
Voici ma meilleure hypothèse jusqu'à présent: je ne sais pas, et ça n'a pas d'importance. P>
Je ne sais pas pourquoi gdb imprime le message "(aucun symbole de débogage trouvé)". J'ai effectivement vu cela lors de la construction de mes propres noyaux. Je configure un noyau pour utiliser les symboles de débogage, mais GDB imprime toujours ce message lorsqu'il regarde l'image du noyau. Je n'ai jamais pris la peine de m'en regarder, car mon image peut toujours être débogé. Malgré le message, GDB peut toujours désassembler des fonctions, ajouter des points d'arrêt, rechercher des symboles et des fonctions à sens unique. Je n'ai jamais remarqué un manque de fonctionnalité de débogage. Je suppose que la même chose vous arrive. P>
edit: strong> basé sur vos commentaires à la question, il semble que vous recherchiez le mauvais symbole avec votre débogueur. Les gestionnaires d'appel système commencent par un préfixe de SYS _ code>, mais vous ne pouvez pas dire à regarder le code. Le macro
syscall_define4 (ptrace, ...) code> vient de finir par déclarer la fonction comme
asmlinkage long long sys_ptrace (...) code>, bien qu'il fait d'autres trucs fous si vous avez Ftrace activé. P>
Make Menuconfig-> piratage du noyau -> [] Débogage du noyau -> [ em>] Compilez le noyau avec des informations de débogage (config_debug_info) P>
L'OP n'a-t-il pas dit qu'il l'a fait déjà? "J'ai configurer toutes les options associées config_debug_ à Y"
Ajouter -g à la variable CFLAGS dans le noyau Makefile P>
Il est également possible lorsque vous emballez votre image Vmlinuz, les symboles de débogage ont été supprimés (lors de l'utilisation de make-kpkg pour créer un package Deb pour le noyau Linux). Vous devez donc utiliser le fichier Vmlinux construit sous votre arborescence source Linux pour que ces symboles de débogage. P>
Pourriez-vous vérifier que votre fichier
.config code> contient la ligne
config_debug_info = y code>?
Oui, j'ai vérifié que plusieurs fois.
Compilez-vous votre propre noyau, déboguer une distribution?
Oui, je compile mon propre noyau, mais pas de symboles de débogage jusqu'à présent ...
Supprimer des fichiers .O dans votre arborescence de construction, puis tapez
faire v = 1 code> pour obtenir la sortie verbeuse. L'appel à GCC comprend-il en fait le drapeau "-g"?
@ Karmastan, j'ai vérifié avec
faire v = 1 code>, et oui il y a le drapeau
-g code>
Dans gdb, quelle est la sortie de
(gdb) b fs / open.c: 10 code>?
C'est
Point d'arrêt 1 à 0xFFFFFFF810D2814: Fichier FS / Open.c, Line 10. Code>
Ensuite, on dirait que vous avez un support de débogage en fonctionnement!
Mais quand j'essaie de voir comment
pTrace code> est implémenté (
l pTrace code>), il n'y a pas de telles info
fonction "ptrace" non définie code> ...
Cela pourrait être parce qu'il n'y a pas de fonction appelée
pTrace () code> dans le noyau. Si vous recherchez le gestionnaire d'appel de système PTRACE, il s'appelle
sys_ptrace code> et est défini dans noyau / pTrace.c . Le macro
syscall_define4 (ptrace, ...) code> définit réellement la fonction
sys_ptrace () code> après que le préprocesseur soit effectué avec celui-ci.
@Compiler: J'aimerais vous rappeler que vous avez une prime ouverte sur cette question. Même si vous n'atteignez pas la prime, vous allez toujours perdre la réputation.