Obtention du numéro de ligne de pdb en mode édition

Question

Est-il possible que le débogueur (ou le gestionnaire d'exceptions CLR) affiche la ligne où l'exception s'est produite en mode Release à l'aide de pdb?

Le code, en mode release, est optimisé et ne suit pas toujours l'ordre et la logique du code "original".

Il est également surprenant que le débogueur puisse naviguer dans mon code pas à pas, même en mode Release. L'optimisation devrait rendre la navigation très inconfortable. Pourriez-vous préciser ces deux points pour moi, s'il vous plaît?

Answer 1

Je ne suis pas aussi familier avec la façon dont cela est fait avec CLR, mais c'est probablement très similaire à la façon dont cela est fait avec du code natif. Lorsque le compilateur génère des instructions machine, il ajoute des entrées au pdb qui disent en gros que "l'instruction à l'adresse actuelle, X, provient de la ligne 25 de foo.cpp".

Le débogueur connaît l'adresse du programme en cours d'exécution. Il recherche donc une adresse, X, dans le fichier pdb et voit qu'elle provient de la ligne 25 de foo.cpp. En utilisant cela, il est capable de "passer" à travers votre code source.

Ce processus est identique quel que soit le mode de débogage ou de libération (à condition qu'un pdb soit généré en mode de libération). Vous avez raison, cependant, que souvent en mode release en raison d'optimisations, le débogueur ne va pas "linéairement" à travers le code. Il pourrait sauter de manière inattendue vers différentes lignes. Cela est dû au fait que l'optimiseur a modifié l'ordre des instructions, mais il ne modifie pas le mappage entre l'adresse et la source, de sorte que le débogueur est toujours capable de le suivre.

Answer 2

Le débogueur fait un meilleur effort pour deviner où le problème s'est produit. Il n'est pas garanti d'être précis à 100%, et avec un code entièrement optimisé, il sera souvent inexact - j'ai trouvé les inexactitudes allant de quelques lignes à une pile d'appels totalement erronée.

La précision du débogueur avec le code optimisé dépend vraiment du code lui-même et des optimisations que vous réalisez.

Answer 3

Référence les éléments suivants SO question:

Display lines number in stack trace for .NET assembly in release mode

Answer 4

[@Not sûr] a presque raison. Le compilateur fait de son mieux pour identifier un numéro de ligne approprié qui correspond étroitement à l'instruction de code machine actuelle.

Le PDB et le débogueur ne connaissent rien aux optimisations; le fichier PDB mappe essentiellement les emplacements d'adresses dans le code machine aux numéros de ligne de code source. Dans le code optimisé, il n'est pas toujours possible de faire correspondre exactement une instruction d'assemblage à une ligne spécifique de code source, de sorte que le compilateur écrira à la PDB la chose la plus proche dont il dispose. Cela peut être "la ligne de code source avant", ou "la ligne de code source du contexte englobant (boucle, etc)" ou autre chose. Quoiqu'il en soit, le débogueur trouve essentiellement l'entrée dans la carte PDB la plus proche (comme dans "before or equal") de l'IP en cours (Instruction Pointer) et met en surbrillance cette ligne.

Parfois, la correspondance n'est pas très bonne, et c'est à ce moment-là que la zone en surbrillance saute partout.