Une plongée approfondie dans les sujets avancés du débogueur Linux

Présentation

Nous arrivons enfin au dernier article de cette série ! Cette fois, je vais donner un aperçu général de certains des concepts les plus avancés du débogage : débogage à distance, prise en charge des bibliothèques partagées, évaluation des expressions et prise en charge du multithreading. Ces idées sont plus complexes à mettre en œuvre, je n'entrerai donc pas dans les détails sur la façon de procéder, mais je serai heureux de répondre aux questions sur ces concepts si vous avez des questions.

Index des séries

1. Préparer l'environnement
2. Point d'arrêt
3. Registres et mémoire
4. Elfes et nains
5. Code source et signaux
6. La couche de code source est exécutée étape par étape
7. Points d'arrêt de la couche de code source
8. Pile d'appels
9. Gérer les variables
10. Thème Premium

Débogage à distance

Le débogage à distance est très utile pour les systèmes embarqués ou le débogage de différents environnements. Il établit également une ligne fine entre les opérations de haut niveau du débogueur et l'interaction avec le système d'exploitation et le matériel. En fait, les débogueurs comme GDB et LLDB peuvent fonctionner comme débogueurs distants même lors du débogage de programmes locaux. La structure générale est la suivante :

debuarch

Le débogueur est le composant avec lequel nous interagissons via la ligne de commande. Peut-être que si vous utilisez un IDE, il y a une autre couche au-dessus qui communique avec le débogueur via l'interface de la machine. Sur la machine cible (probablement la même que la machine native), il existe un stub de débogage, qui est théoriquement un wrapper autour d'une très petite bibliothèque de débogage du système d'exploitation qui effectue toutes les tâches de débogage de bas niveau, comme la définition de points d'arrêt sur les adresses. Je dis "en théorie" parce que les talons de débogage sont de plus en plus gros de nos jours. Par exemple, la taille du stub de débogage LLDB sur ma machine est de 7,6 Mo. Le stub de débogage communique avec le processus débogué et le débogueur via le protocole distant en utilisant certaines fonctionnalités spécifiques au système d'exploitation (ptrace dans notre cas).
Le protocole de débogage distant le plus courant est le protocole distant GDB. Il s'agit d'un format de paquet textuel utilisé pour transmettre des commandes et des informations entre le débogueur et les stubs de débogage. Je n'entrerai pas dans les détails, mais vous pouvez en savoir plus ici. Si vous démarrez LLDB et exécutez la commande log activate gdb-remote packets, vous obtiendrez une trace de tous les paquets envoyés via le protocole distant. Sur GDB, vous pouvez faire la même chose avec set remotelogfile.

À titre d'exemple simple, voici le paquet sur lequel définir un point d'arrêt :

$Z0,400570,1#43

$ marque le début du paquet. Z0 est la commande pour insérer un point d'arrêt mémoire. 400570 et 1 sont des paramètres, le premier étant l'adresse permettant de définir le point d'arrêt et le second le spécificateur de type de point d'arrêt pour une cible spécifique. Enfin, #43 est une somme de contrôle pour garantir que les données ne sont pas corrompues.

Le protocole distant GDB est très facile à étendre avec des paquets personnalisés, ce qui est utile pour implémenter des fonctionnalités spécifiques à une plate-forme ou à un langage.

Bibliothèques partagées et prise en charge du chargement dynamique

Le débogueur doit savoir quelles bibliothèques partagées sont chargées par le programme en cours de débogage afin de pouvoir définir des points d'arrêt, obtenir des informations et des symboles au niveau du code source, etc. En plus de rechercher les bibliothèques liées dynamiquement, le débogueur doit également tracer les bibliothèques chargées au moment de l'exécution via dlopen. Pour atteindre cet objectif, l'éditeur de liens dynamique maintient une structure d'intersection. Cette structure maintient une liste chaînée de descripteurs de bibliothèque partagée, ainsi qu'un pointeur vers une fonction qui est appelée chaque fois que la liste chaînée est mise à jour. Cette structure est stockée dans la section .dynamic du fichier ELF et est initialisée avant l'exécution du programme.

Un algorithme de suivi simple :

• Le traceur recherche l'entrée du programme dans l'en-tête ELF (ou peut utiliser des vecteurs auxiliaires stockés dans /proc//aux).
• Le programme de traçage définit un point d'arrêt à l'entrée du programme et démarre l'exécution.
• Lorsque le point d'arrêt est atteint, recherchez l'adresse de la structure d'intersection en recherchant l'adresse de chargement de .dynamic dans le fichier ELF.
• Vérifiez la structure d'intersection pour une liste des bibliothèques actuellement chargées.
• Définissez un point d'arrêt sur la fonction de mise à jour de l'éditeur de liens.
• La liste est mise à jour à chaque fois qu'un point d'arrêt est atteint.
• Le programme de suivi boucle à l'infini, continuant à exécuter le programme et attendant les signaux jusqu'à ce que le signal du programme de suivi sorte.

J'ai écrit un petit exemple de ces concepts, que vous pouvez retrouver ici. Je pourrai écrire plus en détail à l'avenir si quelqu'un est intéressé.

Calcul d'expression

L'évaluation des expressions est une fonctionnalité du programme qui permet aux utilisateurs d'évaluer les expressions dans la langue source d'origine lors du débogage du programme. Par exemple, dans LLDB ou GDB, vous pouvez exécuter print foo() pour appeler la fonction foo et imprimer le résultat.

Il existe plusieurs méthodes de calcul différentes selon la complexité de l'expression. Si l'expression n'est qu'un simple identifiant, le débogueur peut consulter les informations de débogage, trouver la variable et imprimer la valeur, tout comme nous l'avons fait dans la dernière partie de cette série. Si l'expression est quelque peu complexe, il peut être possible de compiler le code en une expression intermédiaire (IR) et de l'interpréter pour obtenir le résultat. Par exemple, pour certaines expressions, LLDB utilisera Clang pour compiler l'expression dans un LLVM IR et l'interpréter. Si l'expression est plus complexe ou nécessite l'appel de certaines fonctions, le code devra peut-être être envoyé à la cible et exécuté dans l'espace d'adressage du débogué. Cela implique d'appeler mmap pour allouer de la mémoire exécutable, puis de copier le code compilé dans ce bloc et de l'exécuter. LLDB est implémenté à l’aide des capacités JIT de LLVM.

Si vous souhaitez en savoir plus sur la compilation JIT, je vous recommande vivement l'article d'Eli Bendersky sur le sujet.

多线程调试支持

本系列展示的调试器仅支持单线程应用程序，但是为了调试大多数真实程序，多线程支持是非常需要的。支持这一点的最简单的方法是跟踪线程的创建，并解析 procfs 以获取所需的信息。

Linux 线程库称为 pthreads。当调用 pthread_create 时，库会使用 clone 系统调用来创建一个新的线程，我们可以用 ptrace 跟踪这个系统调用（假设你的内核早于 2.5.46）。为此，你需要在连接到调试器之后设置一些 ptrace 选项：

ptrace(PTRACE_SETOPTIONS, m_pid, nullptr, PTRACE_O_TRACECLONE);

现在当 clone 被调用时，该进程将收到我们的老朋友 SIGTRAP 信号。对于本系列中的调试器，你可以将一个例子添加到 handle_sigtrap 来处理新线程的创建：

case (SIGTRAP | (PTRACE_EVENT_CLONE << 8)):
//get the new thread ID
unsigned long event_message = 0;
ptrace(PTRACE_GETEVENTMSG, pid, nullptr, message);
//handle creation
//...

一旦收到了，你可以看看 /proc//task/ 并查看内存映射之类来获得所需的所有信息。

GDB 使用 libthread_db，它提供了一堆帮助函数，这样你就不需要自己解析和处理。设置这个库很奇怪，我不会在这展示它如何工作，但如果你想使用它，你可以去阅读这个教程。

多线程支持中最复杂的部分是调试器中线程状态的建模，特别是如果你希望支持不间断模式或当你计算中涉及不止一个 CPU 的某种异构调试。

最后！

呼！这个系列花了很长时间才写完，但是我在这个过程中学到了很多东西，我希望它是有帮助的。如果你有关于调试或本系列中的任何问题，请在 Twitter @TartanLlama或评论区联系我。如果你有想看到的其他任何调试主题，让我知道我或许会再发其他的文章。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!