Quelles sont les implications de l'utilisation de /Zi vs /Z7 pour les projets C++ de Visual Studio?
Background
Il y a plusieurs différents les indicateurs de débogage vous pouvez l'utiliser avec le compilateur C++ de Visual Studio. Ils sont les suivants:
- (aucun)
- Créer aucune information de débogage
- temps de compilation plus rapides
- / Z7
- Produire toute la symbolique des informations de débogage dans le .fichiers obj utilisant CodeView format
- / Zi
- produire des informations de débogage pleinement symboliques dans A.fichier pdb pour la cible en utilisant le format de la base de données du programme.
- permet la prise en charge de reconstructions minimales (/Gm) qui peuvent réduire le temps nécessaire à la recompilation.
- / ZI
- produire des informations de débogage comme / Zi sauf avec le support pour Edit-et-Continuer
le drapeau / Gm est incompatible avec le /MP drapeau pour Plusieurs Processus s'appuie (Visual Studio 2005/2008)
si vous voulez activer les reconstructions minimales, alors le drapeau /Zi est nécessaire au-dessus du drapeau /Z7.
si vous allez utiliser le drapeau / MP, il n'y a apparemment aucune différence entre /Z7 et /Zi en regardant MSDN. Cependant, l' SCons documentation indique que vous devez utiliser /Z7 pour supporter les constructions parallèles.
Questions
quelles sont les implications de l'utilisation de /Zi vs /Z7 dans un projet C++ de Visual Studio?
existe-il d'autres pros ou les inconvénients de ces deux options que j'ai manqué?
en particulier, quel est l'avantage d'un fichier de base de données de programme unique (PDB) pour le vs cible format à codes multiples (.obj) des fichiers pour chaque source?
Références
MDSN /Z7, / Zi, / ZI (Debug Information Format)
MSDN / MP (Build with Multiple Processes)
4 réponses
Codeview est un format de débogage beaucoup plus ancien qui a été introduit avec L'ancien débogueur autonome de Microsoft à l'époque du "compilateur Microsoft C" au milieu des années 1980. Cela prend plus de place sur le disque et cela prend plus de temps au débogueur à analyser, et c'est une douleur majeure à traiter pendant la liaison. Nous l'avons généré à partir de notre compilateur lorsque je travaillais sur le CodeWarrior pour Windows en 1998-2000.
Le seul avantage, c'est que Codeview est un format documenté, et d'autres outils souvent le traiter quand ils ne pouvaient pas traiter avec des bases de données de débogage PDB-format. En outre, si vous construisez plusieurs fichiers à la fois, il n'y a aucune prétention à écrire dans la base de données de débogage pour le projet. Cependant, pour la plupart des utilisations ces jours-ci, utiliser le format PDB est une grande victoire, à la fois dans le temps de construction et surtout dans le temps de démarrage du débogueur.
un avantage de l'ancien format C7 est qu'il est tout-en-un, stocké dans L'EXE, au lieu d'un PDB et D'un EXE séparés. Cela signifie que vous ne pouvez jamais avoir une incompatibilité. Les outils VS dev vont s'assurer qu'un PDB corresponde à son EXE avant qu'il ne l'utilise, mais il est certainement plus simple d'avoir un seul EXE avec tout ce dont vous avez besoin.
cela ajoute de nouveaux problèmes de devoir être en mesure de rayer les informations de débogage lorsque vous lancez, et le fichier EXE géant, sans mentionner le format antique et le manque de le soutien pour d'autres traits modernes comme minrebuild, mais il peut toujours être utile quand vous essayez de garder les choses aussi simples que possible. Un dossier est plus facile que deux.
ce n'est pas que j'utilise le format C7, je le présente simplement comme un avantage possible, puisque vous me le demandez.
soit dit en passant, C'est comme ça que GCC fait les choses sur quelques plateformes que j'utilise. Format DWARF2 enfoui dans les ELF de sortie. Les gens d'Unix pensent qu'ils sont hilarants. :)
BTW L'APB le format peut être analysé en utilisant le DIA SDK.
il y a un inconvénient de plus pour /Z7: Il n'est pas compatible avec les liens incrémentiels, qui peuvent être une seule raison de l'éviter. Lien: http://msdn.microsoft.com/en-us/library/4khtbfyf%28v=vs.100%29.aspx
soit dit en passant: même si Microsoft dit qu'un lien complet (au lieu d'un incrémental) est Exécuté quand "un objet qui a été compilé avec l'option /YU /Z7 est modifié.", il semble que cela ne soit vrai que pour les bibliothèques statiques construites avec / Z7, pas pour les objets fichier.
un Autre inconvénient de /Z7 est la grande taille des fichiers objets. Cela a déjà été mentionné ici, mais cela peut dégénérer jusqu'au point où le linker est incapable de lier l'exécutable parce qu'il viole la limite de taille du linker ou le format PE (il vous donne l'erreur de linker LNK1248). Il semble que Visual Studio ou le format PE ont une limite dure de 2 Go (également sur les machines x64). Lorsque vous construisez une version de débogage, vous pouvez entrer dans cette limite. Il semble que cela n'affecte pas seulement la taille de la finale exécutable compilé, mais aussi des données temporaires. Seul Microsoft connaît les internes de linker, mais nous avons rencontré ce problème ici (bien que l'exécutable n'était bien sûr pas 2gigs large, même dans le debug). Le problème a miraculeusement disparu et n'est jamais revenu lorsque nous avons changé le projet en /ZI.