Je suis en dehors de l'exécutable cible de gdb et je n'ai même pas de pile correspondant à cette cible. Je veux quand même faire une seule étape, afin de pouvoir vérifier ce qui se passe dans mon code d'assemblage, car je ne suis pas un expert en assemblage x86. Malheureusement, gdb refuse d'effectuer ce simple débogage au niveau de l'assembly. Cela me permet de définir et de m'arrêter sur un point d'arrêt approprié, mais dès que j'essaye d'avancer d'une seule étape, gdb signale l'erreur «Impossible de trouver les limites de la fonction actuelle» et l'EIP ne change pas.
Détails supplémentaires:
Le code machine a été généré par des instructions gcc asm et je l'ai copié dans l'emplacement mémoire du noyau où il s'exécute, à partir de la sortie de objdump -d. Cela ne me dérangerait pas d'utiliser un chargeur pour charger mon code objet à une adresse déplacée, mais gardez à l'esprit que le chargement doit être effectué dans un module du noyau.
Je suppose qu'une autre alternative serait de produire un faux module de noyau ou un fichier d'informations de débogage à donner à gdb, pour lui faire croire que cette zone est dans le code du programme. gdb fonctionne correctement sur l'exécutable du noyau lui-même.
(Pour ceux qui veulent vraiment le savoir, j'insère du code au moment de l'exécution dans l'espace de données du noyau Linux à l'intérieur d'une VM VMware et je le débogue à partir de gdb à distance en déboguant le noyau via le stub gdb intégré de VMware Workstation. Remarque je n'écris pas le noyau exploits; je suis un étudiant diplômé en sécurité qui écrit un prototype.)
(Je peux définir un point d'arrêt sur chaque instruction dans mon assemblage. Cela fonctionne mais deviendrait assez laborieux après un certain temps, car la taille des instructions d'assemblage x86 varie et l'emplacement de l'assemblage changera à chaque redémarrage.)