Comment fonctionne le débogueur Rust sous le capot : analyse pas à pas

Débogueur Rust : comment regarder sous le capot step by step

Vous êtes-vous déjà demandé : « Step by step interactive debugger for Rust : comment ça marche sous le capot ? » Si vous avez programmé en Rust et tenté de traquer un bug retors, vous avez sûrement rencontré GDB, LLDB ou même des outils comme rust-gdb. Mais comment parviennent-ils à arrêter l'exécution d'un programme, à afficher les valeurs des variables et à parcourir le code source pas à pas ?

Dans cet article, nous ne nous contenterons pas d'expliquer comment utiliser le débogueur. Nous allons regarder à l'intérieur : du code machine aux points d'arrêt, des cadres de pile aux symboles de débogage. Si vous voulez savoir non seulement quoi faire, mais aussi pourquoi cela fonctionne, vous êtes au bon endroit.

Pourquoi Rust est-il un cas particulier pour le débogage ?

Rust est compilé en code natif via LLVM. Cela signifie que pour le débogage, nous utilisons les mêmes outils que pour le C/C++ : GDB et LLDB. Mais Rust ajoute ses propres complexités :

\n
• Propriété et emprunt — les variables peuvent être déplacées, et le débogueur doit le suivre.
\n
• Monomorphisation des génériques — chaque T se transforme en un type concret, et les noms de fonctions deviennent « chiffrés ».
\n
• Optimisations — le compilateur peut réorganiser le code, et le débogueur doit « dérouler » cela en sens inverse.
\n

C'est pourquoi le step by step interactive debugger for Rust n'est pas simplement un lancement de programme sous GDB. C'est tout un système qui traduit les adresses machine en lignes de code source.

Comment fonctionne un point d'arrêt (breakpoint) sous le capot ?

Imaginez : vous placez un point d'arrêt sur la ligne println!("Hello");. Que se passe-t-il dans le processeur ?

Lorsque vous lancez un programme sous le débogueur, il effectue les opérations suivantes :

\n
1. Il lit les informations de débogage (format DWARF) dans le fichier exécutable. Elles contiennent la correspondance : adresse mémoire → ligne dans le code.
\n
2. Il remplace l'instruction à cette adresse par une commande spéciale INT3 (sur x86 — 0xCC). C'est un « piège » pour le processeur.
\n
3. Lorsque l'exécution atteint ce point, le processeur génère un signal SIGTRAP.
\n
4. Le débogueur intercepte le signal, sauvegarde l'état des registres et vous affiche la ligne actuelle.
\n

Voici un exemple de programme simple en Rust :

fn main() {\n    let x = 42;\n    let y = x + 10; // <-- point d'arrêt\n    println!("y = {}", y);\n}

Lorsque vous placez un breakpoint sur let y = x + 10;, le débogueur trouve l'adresse de cette instruction dans le binaire et remplace le premier octet par 0xCC. Après l'arrêt, il restaure l'octet d'origine, exécute l'étape, puis replace le piège — si vous souhaitez continuer.

Step over, step into, step out — comment le débogueur sait-il où se trouve la « ligne suivante » ?

C'est sans doute la partie la plus magique. Comment le débogueur sait-il qu'après let y = x + 10; vient println! ?

Tout est question de tables de débogage. Le compilateur Rust (via LLVM) génère une section .debug_line au format DWARF. C'est une table compressée qui fait correspondre les adresses des instructions aux numéros de ligne dans le code source.

Par exemple, pour notre code, la table pourrait ressembler à ceci :

Adresse 0x1000 → ligne 2 (let x = 42;)\nAdresse 0x1010 → ligne 3 (let y = x + 10;)\nAdresse 0x1020 → ligne 4 (println!)

Lorsque vous appuyez sur step over, le débogueur calcule l'adresse de l'instruction suivante qui n'appartient pas à la ligne actuelle, et y place un point d'arrêt temporaire. L'exécution continue jusqu'à cette adresse — et vous passez à la ligne suivante.

Pour step into — le débogueur vérifie s'il y a un appel de fonction à l'adresse actuelle. Si oui, il cherche la première ligne de cette fonction