2009-02-09 8 views
7

Nous utilisons actuellement un outil de ligne de commande unique pour construire notre produit sur Windows et Linux.Comment fusionner plusieurs fichiers PDB?

Si loin fonctionne bien, ce qui nous permet de construire à partir de la source et avec des dépendances plus fines que ce que notre système de construction précédent a permis. Cela nous achète de grandes capacités de construction incrémentielles et parallèles.

Pour décrire brièvement le processus de construction, nous obtenons l'habituel:

.cpp -- cl.exe --> .obj and .pdb 
multiple .obj and .pdb -- cl.exe --> single .dll .lib .pdb 
multiple .obj and .pdb -- cl.exe --> single .exe .pdb 

Le msvc C/C++ supporte de manière adéquate.

Récemment, le besoin de construire quelques bibliothèques statiques a émergé. D'après ce que nous avons recueilli, le processus de construction d'une bibliothèque statique est:

multiple .cpp -- cl.exe --> multiple .obj and a single .pdb 
multiple .obj -- lib.exe --> a single .lib 

Le pdb unique signifie que cl.exe ne doit être exécutée une fois pour toutes les sources de Cpp. Cette seule exécution signifie que nous ne pouvons pas paralléliser la construction de cette bibliothèque statique. C'est vraiment malheureux.

Nous avons étudié un peu plus loin et selon la documentation (et les options de ligne de commande disponibles):

  • cl.exe ne sait pas comment construire des bibliothèques statiques
  • lib.exe ne sait pas comment construire pdb fichiers

Est-ce que quelqu'un sait un moyen de fusionner plusieurs fichiers PDB? Sommes-nous condamnés à avoir des constructions lentes pour les bibliothèques statiques? Comment les outils comme Incredibuild fonctionnent-ils autour de ce problème?

+0

Vous pouvez toujours placer votre code sur un lecteur SSD. Les constructions seront rapides comme l'éclair. –

+0

Je suis en état de conduire sur mon stylebook. Cela aide, mais la liaison est liée à l'E/S, la compilation est liée à l'UC. –

Répondre

5

Je n'ai pas fait C++ depuis longtemps mais à partir de ce article, il semble que ce soit une astuce de performance pour arrêter la recréation de symboles pour les en-têtes communs.

Vous pouvez essayer/Z7 d'intégrer des informations dans chaque obj, et ne pas créer un PDB, puis lier et recréer avec un rebase comme dans ce article.

+0

Les informations de débogage de/Z7 ne sont-elles pas différentes (et inférieures) de ce qui est généré par/Zi et/ZI? Selon l'article lié à dans le thead café (http://support.microsoft.com/kb/258205) vous pouvez extraire les informations de débogage de/Z7 dans un fichier .dbg et non un fichier .pdb. –

+1

ces deux liens sont maintenant morts :( –

5

Pas besoin de fusionner les fichiers PDB.

Compilez les fichiers sources avec/Z7 pour éviter de créer un PDB pendant les étapes CL.EXE. Utilisez LIB.EXE pour créer des librairies statiques avec des informations de débogage intégrées.

Utilisez LINK.EXE au lieu de CL.EXE pour lier, utilisez/PDB pour spécifier où les informations de débogage vont.

Si vous déboguez un processus avec un fichier EXE et une ou plusieurs DLL, alimentez votre débogueur un PDB pour chaque image (EXE ou DLL).

2

Les fichiers PDB de fusion sont possibles, mais seuls cl.exe et link.exe peuvent le faire. Je ne connais pas d'outils autonomes pour fusionner des fichiers PDB.

Vous pouvez utiliser l'option/PDB de l'éditeur de liens (j'ai coché VC2005) pour spécifier un autre nom de fichier pdb.

Microsoft suggère d'inclure également les fichiers PDB (chaque obj a un fichier PDB correspondant) avec le fichier .LIB.

Vous ne pouvez pas archiver les fichiers PDB dans le fichier .LIB, je l'ai essayé avec VC2003, échoué.

La compilation avec/Z7 permet d'éviter les fichiers PDB pour .LIB, mais les fichiers objets sont volumineux, sauf si link.exe supprime les informations de débogage. Si vous n'avez pas d'option/debug pour l'éditeur de liens, votre fichier exe/dll ne peut pas être débogué.

Le compilateur (cl.exe) écrit toujours dans le fichier vcXX.pdb sauf si vous utilisez l'option/fd pour spécifier un autre nom. Même lorsque vous utilisez cl.exe pour produire un exécutable "directement", il va produire un fichier vc80.pdb, puis le fichier link.exe produira le même nom de fichier pdb que l'exécutable.

cl/Zi test.c

cl.exe -> vc80.pdb link.exe lire vc80.pdb (le nom est intégré dans test.obj fichier) -> test.pdb

Chaque fois que cl/Zi/c compile un fichier, il essaye de modifier le fichier vcXX.pdb existant au lieu de l'écraser. J'ai la console ci-dessus en jouant avec le compilateur encore et encore, puis capturez le résultat du procexp de sysinternals et l'analysez. J'espère que cela aide.

0

Sauf si vous voulez redistribuer les bibliothèques statiques avec des informations de débogage, vous n'avez pas réellement besoin de fusionner les fichiers PDB (ou utiliser /Z7 pour intégrer les informations de débogage). Comme @zhaorufei mentionné, lorsque vous utilisez /Zi, chaque fichier objet contient une référence à son fichier PDB, que l'éditeur de liens utilise ensuite.

Utilisez simplement /Fd pour donner à chaque objet un fichier PDB unique:

> cl -c foo.cpp -Fo:target/foo.obj -Fd:target/foo.pdb -Zi 
> cl -c bar.cpp -Fo:target/bar.obj -Fd:target/bar.pdb -Zi 

> strings target/foo.obj | grep pdb 
D:\Dev\sample\target\foo.pdb 
> strings target/bar.obj | grep pdb 
D:\Dev\sample\target\bar.pdb 

Cela a aussi l'avantage que cela fonctionne autour des questions d'accès simultané aux fichiers PDB partagés mentionnés here, de sorte que vous pouvez paralléliser la compilation marche comme tu voulais.

Puis liez/archivez les fichiers objet comme d'habitude. VC++ intègre déjà différents types d'informations dans les fichiers objets pour les transmettre à l'éditeur de liens, tels que le paramètre de liaison d'exécution et les bibliothèques de dépendances - le chemin du fichier PDB n'est pas différent. Création d'une bibliothèque statique des objets ne supprime pas les références:

> lib -out:target/all.lib target/foo.obj target/bar.obj 
> strings target/all.lib | grep pdb 
D:\Dev\sample\target\bar.pdb 
D:\Dev\sample\target\foo.pdb 

En liant cette bibliothèque à un fichier exécutable ou DLL, l'éditeur de liens tire toujours dans les informations de débogage des PDB fait référence et il ajoute au fichier final APB . La seule mise en garde que je peux voir est que le chemin est toujours absolu, donc cela peut ne pas fonctionner si vous déplacez les fichiers localement ou sur une autre machine avant la liaison.

Questions connexes