Les optimisations peuvent-elles affecter la capacité à déboguer une application VC++ à l'aide de sa PDB?

Question

Afin de pouvoir déboguer correctement les versions de version, un fichier PDB est nécessaire. Le fichier PDB peut-il devenir moins utilisable lorsque le compilateur utilise différents types d'optimisations (FPO, PGO, fonctions intrinsèques, inlining, etc.)? Si oui, l'effet de l'optimisation est-il grave ou fait-il simplement confondre les lignes de code adjacentes?

(j'utilise VC2005, et sera toujours choisir debugability sur des performances optimisées - mais la question est générale)

Answer 1

Oui, le code optimisé est moins débogable. Non seulement certaines informations sont manquantes, mais certaines informations seront très trompeuses.

Le plus gros problème à mon avis est les variables locales. Le compilateur peut utiliser la même adresse de pile ou enregistrer plusieurs variables dans une fonction. Comme d'autres affiches l'ont mentionné, parfois même trouver ce que le pointeur "this" peut prendre un peu de temps. Lors du débogage du code optimisé, vous pouvez voir la ligne en cours de saut en une seule étape, puisque le compilateur a réorganisé le code généré. Si vous utilisez PGO, ce saut va probablement empirer. Le FPO ne devrait pas trop affecter le débogage, à condition d'avoir un PDB puisque la PDB contient toutes les informations nécessaires pour dérouler la pile pour les trames FPO. FPO peut être un problème lors de l'utilisation d'outils qui doivent prendre des traces de pile sans symboles. Pour de nombreux projets, les avantages du FPO en termes de performance ne l'emportent pas sur le succès de la diagnosticabilité; pour cette raison, MS a décidé de ne pas construire Windows Vista avec l'optimisation FPO (http://blogs.msdn.com/larryosterman/archive/2007/03/12/fpo.aspx).Je préfère déboguer du code non optimisé mais ce n'est pas toujours possible - certains problèmes ne reprennent que du code optimisé, les vidages sur incident des clients proviennent de la version validée et l'obtention d'un débogage privé n'est parfois pas possible. Souvent, lors du débogage du code optimisé, j'utilise la vue de démontage - le désassemblage ne ment jamais.

Tout cela s'applique à windbg puisque je fais tout le débogage de code natif avec elle. Le débogueur de Visual Studio peut mieux gérer certains de ces cas.

Answer 2

Oui. Cela peut parfois être grave, bien que ce soit généralement le résultat de l'insertion ou de la réorganisation du code.

Les variables locales peuvent également ne pas être affichées avec précision dans la fenêtre de surveillance, car elles peuvent seulement exister dans les registres et peuvent ne pas s'afficher correctement lorsque vous changez de cadre de pile.

Answer 3

L'optimisation peut avoir un impact important sur le débogage sur n'importe quelle plate-forme (pas seulement les fichiers PDB de VC).

Exactement pour les raisons que vous avez mentionnées, la fonction Inline peut dans certains cas complètement confondre les instructions qui appartiennent à quelle fonction (puisqu'elles font parfois partie des deux).

Une optimisation courante consiste également à effectuer des trames de pile "sales" (-fomit-frame-pointer dans GCC), ce qui empêche le code de suivre le sommet de la pile. C'est très bien, cela libère un registre supplémentaire (ebp sur x86) pour les autres opérations. Mais il est quasiment impossible de dérouler la pile pour voir ce qui se passe réellement. Il est également quasiment impossible de trouver des variables locales et des paramètres de fonction sur la pile.

En général: Ne vous attendez pas à obtenir des informations de débogage utiles sur les versions "release". Si le débogage est si important, même à la sortie, vous devriez plutôt "libérer" les versions de débogage.

Answer 4

En plus des variables locales, le pointeur 'this' est généralement optimisé dans les versions optimisées. Cela peut parfois être contourné en montant suffisamment dans la pile d'appels au point où le pointeur ou la référence d'objet existe en tant que variable non optimisée.

En général. Le simple pas dans la construction optimisée fonctionne généralement plus ou moins et permet de voir quelles décisions logiques le code rend. L'examen des données sur lesquelles ces décisions sont basées est généralement beaucoup plus compliqué.