pdb fait référence au fichier "base de données du programme", qui est un fichier généré lorsque VS est compilé et lié. Le fichier DPB stocke principalement les informations de base requises par VS lors du débogage du programme, notamment le nom du fichier source, le nom de la variable, le nom de la fonction, le FPO, le numéro de ligne correspondant, etc. Le fichier PDB est généré lors de la compilation du projet, et il est généré avec le module correspondant.
L'environnement d'exploitation de ce tutoriel : système Windows 7, ordinateur Dell G3.
PDB (Program DataBase), le nom complet est le fichier "Program Database", qui est un fichier généré lorsque VS est compilé et lié. Le fichier DPB stocke principalement les informations de base requises par VS lors du débogage du programme, notamment le nom du fichier source, le nom de la variable, le nom de la fonction, le FPO (pointeur de trame), le numéro de ligne correspondant, etc. Les informations de débogage étant stockées, les fichiers PDB sont généralement générés en mode débogage.
Les informations pertinentes sur le chemin du fichier source sont enregistrées dans le fichier PDB, donc lors du chargement du fichier PDB, les informations de débogage pertinentes peuvent être mises en correspondance avec le code source. Cela vous permet de visualiser visuellement les appels de fonction, les valeurs des variables et d'autres informations associées pendant le débogage en temps réel. Le fichier PDB enregistré dans le module est un chemin absolu. Ainsi, tant que le module est chargé sur l'ordinateur actuel, le débogueur trouvera naturellement le fichier PDB correspondant en fonction des informations de chemin dans le module et le chargera. De même, le chemin du fichier source enregistré dans le fichier PDB est également un chemin absolu, donc tant que le fichier PDB est chargé sur l'ordinateur actuel et débogué dans le module correspondant, il peut correspondre au fichier source enregistré, puis afficher visuellement le informations correspondantes.
Quand le fichier PDB sera-t-il généré ?
Le fichier PDB est généré lorsque nous compilons le projet. Il est généré avec le module correspondant (exe ou dll). Nous ne réalisons généralement pas l’importance des fichiers PDB, car si nous développons uniquement localement, nous pouvons toujours procéder à des ajustements. Ici, je souhaite introduire deux concepts : Private Build et Public Build1. Private Build fait référence à la compilation sur la machine de développement et Public Build fait référence à la compilation sur la machine responsable de la compilation.
Comme je l'ai dit plus haut, il n'y a généralement aucun problème avec Private Build, car tous les fichiers nécessaires au débogage sur la machine compilée sont là où ils devraient être. La plupart des problèmes qui ne peuvent pas être débogués se produisent dans le cas de Public Build.
Si votre application doit être publiée ou vendue en tant que produit, vous devez accorder une attention particulière à la sauvegarde du fichier PDB et du fichier source de la version que vous publiez. Remarque : Vous n'avez qu'une seule chance de sauvegarder le fichier PDB publié. Si vous le perdez, vous ne pourrez pas le récupérer. 2 (La raison est expliquée ci-dessous)
Pourquoi PDB est-il si important ?
Peut-être que vous pensera que si vous prenez, recompilez simplement un fichier PDB avec exactement le même code source, puis utilisez-le pour le débogage. Je le pensais, jusqu'au jour...
La raison directe est que la partie en-tête du fichier binaire généré par VS contient le GUID de son PDB correspondant, et le PDB contient également un GUIID. deux GUID sont ajoutés lors de la compilation. Le débogueur VS comparera les deux GUID lors du chargement du PDB. S'ils sont incohérents, ils ne pourront pas être utilisés.
Bien sûr, la raison ci-dessus n'est qu'un phénomène superficiel. La raison fondamentale est que les fichiers compilés par le compilateur peuvent être différents de deux codes identiques. Étant donné que le compilateur optimisera le code lors de la compilation et que le même code peut avoir de nombreuses méthodes d'optimisation, il choisira la méthode de génération la plus rapide en fonction de l'environnement machine spécifique du moment. Les fichiers qu'il génère peuvent donc être différents ! Ainsi, si même les fichiers générés sont différents, alors les adresses correspondant aux symboles dans le PDB d'origine n'auront aucun sens.
Comment afficher le GUID des fichiers binaires et des PDB ?
Utilisez l'outil DUMPBIN fourni avec VS pour afficher le GUID du PDB attendu par le fichier binaire. L'utilisation de base est le fichier DUMPBIN /HEADER. Pour une utilisation spécifique, veuillez vous référer à MSDN (http://msdn.microsoft.com/zh-cn/library/c1h23y6c(v=vs.80).aspx).
Pour afficher le GUID du PDB, vous pouvez utiliser l'outil suivant et extraire directement le PDB.
http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P
Stratégie de recherche pour les fichiers PDB
Les résultats des tests sont affichés en premier, puis vous pouvez trouver la stratégie de recherche du symbole d'un module à partir du port série du module de Visual Studio pendant le débogage. À partir de la capture d'écran, nous pouvons voir les résultats comme suit :
1. L'adresse où le fichier est exécuté ou chargé
2. codé dans le fichier PE l'adresse dans l'en-tête. Vous pouvez voir que obj
2.5 Si un serveur de symboles est configuré, après la deuxième étape, vous devez d'abord rechercher dans le répertoire cache du serveur de symboles. Si vous ne le trouvez pas, accédez au serveur de symboles pour le trouver. S'il est trouvé, il sera téléchargé dans le répertoire cache.
3. La troisième partie concerne les répertoires de certaines requêtes de symboles définies dans mon VS. Parce que j'ai installé Reflector, ces répertoires sont ajoutés à mes paramètres par défaut.
4. Dossier Windows.
Un phénomène intéressant ici est que la stratégie de recherche de VS trouvera d'abord symbolexeproject.pdb dans un répertoire, puis exeproject.pdb et enfin project.pdb. Cet ordre est quelque peu surprenant.
Les fichiers PDB affecteront-ils les performances ?
Certaines personnes peuvent penser que la génération de fichiers PDB aura un certain impact sur les performances de l'application finale, elles estiment donc que les fichiers PDB ne devraient pas être générés dans la version finale.
Faux ! Pour les applications .NET, la génération de fichiers PDB n'affectera pas l'optimisation du compilateur et n'affectera donc pas du tout les performances de l'application. Cela n'affectera qu'un seul attribut DebuggableAttribute dans l'assembly généré. Ceux qui sont intéressés peuvent lire Les fichiers PDB affectent-ils les performances ?
Recommandations de didacticiels vidéo connexes : "Tutoriel ASP.NET"
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!