Comment : déboguer le code optimisé
Mise à jour : novembre 2007
Cette rubrique s'applique à :
Édition |
Visual Basic |
C# |
C++ |
Web Developer |
|---|---|---|---|---|
Express |
.gif) |
|
Natif uniquement |
|
Standard |
|
|
Natif uniquement |
|
Pro et Team |
|
|
Natif uniquement |
|
Légende du tableau :
.gif) |
Applicable |
|
Non applicable |
.gif) |
Commande ou commandes masquées par défaut. |
.gif "Remarque") Remarque : |
|---|
Les boîtes de dialogue et les commandes de menu qui s'affichent peuvent être différentes de celles qui sont décrites dans l'aide, en fonction de vos paramètres actifs ou de l'édition utilisée. Pour modifier vos paramètres, choisissez Importation et exportation de paramètres dans le menu Outils. Pour plus d'informations, consultez Paramètres Visual Studio. |
Lorsque le compilateur optimise le code, il repositionne et réorganise les instructions, produisant ainsi un code compilé plus efficace. En raison de cette réorganisation, le débogueur ne peut pas toujours identifier le code source qui correspond à un jeu d'instructions.
L'optimisation peut affecter :
Les variables locales, qui peuvent être supprimées par l'optimiseur ou être déplacées vers des emplacements que le débogueur ne comprend pas.
Des positions à l'intérieur d'une fonction, qui sont modifiées lorsque l'optimiseur fusionne des blocs de code.
Des noms de fonction pour trames sur la pile des appels, qui peuvent être faux si l'optimiseur fusionne deux fonctions.
Les trames qui s'affichent sur la pile des appels sont presque toujours correctes, à condition toutefois que vous ayez des symboles pour toutes les trames. Les trames de la pile des appels seront incorrectes en cas d'altération de la pile, ou si certaines fonctions sont écrites en langage assembleur, ou encore s'il y a des trames de système d'exploitation sans correspondance avec les symboles figurant dans la pile des appels.
Les variables globales et statiques s'affichent toujours correctement. C'est également le cas pour les dispositions de structures. Si un pointeur désigne une structure et que la valeur de ce pointeur est correcte, chaque variable membre de la structure affichera la valeur correcte.
En raison de ces limitations, vous devez effectuer le débogage en utilisant si possible une version non optimisée de votre programme. Par défaut, l'optimisation est désactivée dans la configuration Debug d'un programme Visual C++ et activée dans la configuration Release.
Parfois, cependant, un bogue peut apparaître seulement dans la version optimisée d'un programme. Dans ce cas, vous devez déboguer le code optimisé.
Pour activer l'optimisation dans une configuration de génération Debug
Lorsque vous créez un projet, sélectionnez la cible Win32 Debug. Utilisez la cible Win32Debug jusqu'à ce que votre programme soit entièrement débogué et que vous soyez prêt à générer une cible Win32 Release. Le compilateur n'optimise pas la cible Win32 Debug.
Sélectionnez le projet dans l'Explorateur de solutions.
Dans le menu Affichage, cliquez sur Pages de propriétés.
Dans la boîte de dialogue Pages de propriétés, assurez-vous que Debug est sélectionné dans la zone de liste Configuration.
Dans l'affichage des dossiers, sur le côté gauche, sélectionnez le dossier C/C++.
Sous le dossier C++, sélectionnez Optimization.
Dans la liste des propriétés affichée à droite, recherchez Optimization. Le paramètre en regard de la propriété indique probablement Disabled (/Od). Sélectionnez l'une des autres options (Minimum Size(/O1), Maximum Speed(/O2), Full Optimization(/Ox) ou Custom).
Si vous avez choisi l'option Custom pour Optimization, vous pouvez maintenant définir des options pour l'une des autres propriétés affichées dans la liste des propriétés.
Lorsque vous déboguez un code optimisé, examinez la fenêtre Code Machine pour savoir quelles instructions sont réellement créées et exécutées. Lorsque vous définissez des points d'arrêt, vous devez être conscient qu'un point d'arrêt peut se déplacer avec une instruction. Considérons par exemple le code suivant :
for (x=0; x<10; x++)
Supposons que vous définissez un point d'arrêt sur cette ligne. Vous pouvez escompter que le point d'arrêt sera atteint 10 fois ; mais si le code est optimisé, il ne sera atteint qu'une seule fois. Cela est dû au fait que la première instruction affecte à x la valeur 0. Le compilateur reconnaît que cela ne doit être fait qu'une seule fois et quitte la boucle. Le point d'arrêt est déplacé en même temps.
Les instructions qui comparent et incrémentent x restent à l'intérieur de la boucle. Lorsque vous affichez la fenêtre Code Machine, l'unité de progression est automatiquement réglée sur Instruction pour un contrôle renforcé, ce qui est utile lorsque vous exécutez le code optimisé pas à pas.