Le fichier PDB est plus grand lors de la deuxième compilation, puis reste de la même taille.

Question

En utilisant le fichier simple suivant :

using System;

public class Program{
        [STAThread]
        public static void Main(string[] args){
            Console.WriteLine("Boo");
        }
}

Et puis en utilisant la commande suivante :

csc /target:exe /debug:pdbonly HelloWorld.cs

Si vous exécutez cette commande et que le PDB n'existe pas déjà, alors la taille du fichier PDB est de 12 Ko. Sinon, si le fichier PDB existe déjà, alors la nouvelle taille est de 14 Ko.

Microsoft (R) Visual C# Compiler version 4.0.30319.17929
.NET 4.5

Quelqu'un a des idées pour expliquer cela ?

MISE À JOUR :

1. Je ne rencontre pas ce problème avec .NET 3.5 et d'après les commentaires, pas non plus avec .NET 4.
2. En utilisant pdb2xml (http://blogs.msdn.com/b/jmstall/archive/2005/08/25/sample-pdb2xml.aspx), je ne vois aucune différence entre le petit et le grand.

Answer 1

Ma réponse est simple, mais peut-être pas si précise. Utilisons un outil de débogage sur nos fichiers PDB :

La seule différence est le champ PdbAge. Cela signifie que le fichier PDB n'est pas recréé après chaque compilation ! Ce fichier est modifié, c'est pourquoi sa taille change.

Ma supposition est confirmée dans cet article. Citation:

Une des motivations les plus importantes pour le changement de format était de permettre le lien incrémental des versions de débogage des programmes, un changement introduit pour la première fois dans Visual C++ version 2.0.

Une autre question est ce qui est exactement modifié dans ce fichier ? L'explication la plus détaillée du format de fichier que j'ai trouvée est dans le livre "Sven B. Schreiber, “Undocumented Windows 2000 Secrets: A Programmer’s Cookbook”". La phrase clé est :

Un avantage encore plus grand du format PDB devient apparent lors de la mise à jour d'un fichier PDB existant. Insérer des données dans un fichier avec une structure séquentielle signifie généralement réorganiser de larges portions du contenu. La structure d'accès aléatoire du fichier PDB empruntée aux systèmes de fichiers permet l'ajout et la suppression de données avec un effort minimal, tout comme les fichiers peuvent être modifiés aisément sur un support de système de fichiers. Seul le répertoire de flux doit être réorganisé lorsqu'un flux s'étend ou se rétrécit à travers une limite de page. Cette propriété importante facilite la mise à jour incrémentielle des fichiers PDB.

Il décrit que toutes les données dans le fichier ne sont pas utiles à chaque instant. Certains plages d'octets sont simplement remplis de zéros jusqu'à ce que le fichier soit modifié lors de la prochaine compilation.

Je ne peux donc pas dire ce qui a été exactement modifié dans le fichier PDB, sauf quelques GUID et numéros de version. Vous pouvez approfondir la lecture de ce livre. Bonne chance !

MISE À JOUR (15/03/2013):

J'ai passé un peu plus de temps à comparer les fichiers. Quand je les ouvre en mode HEX, je vois les différences dans l'en-tête : La taille de la page du fichier est de 512 octets (valeur 200h à +20h) et le nombre de pages est différent : 120 et 124 (078h et 07Ch respectivement). Sur mes écrans, le fichier le plus petit est à gauche. D'accord. La différence de taille de fichier est exactement de 2048 octets. Cela signifie que le compilateur ajoute 4 pages de données lors de la seconde fois. Ensuite, j'ai trouvé toutes les autres différences. Les 3/4 du fichier depuis le début contiennent de petites différences - quelques octets comme d'habitude. Mais au point 2600h, nous voyons :

Regardez! La ligne /LinkInfo./names./src/files/c:\Windows\microsoft.net\framework\v4.0.30319\helloworld.cs est maintenant tronquée et contient des informations incohérentes.

J'ai continué et j'ai trouvé cette ligne dans le second fichier (plus grand) en représentation complète : Ces informations ont été placées dans un espace libre maintenant (voir les zéros du côté gauche). Je suppose que les anciennes pages (avec la chaîne corrompue) ont été marquées comme espace inutilisé.

Et à la fin du fichier, j'ai trouvé exactement 2048 octets d'informations nouvelles - tous sont des zéros. À partir de 2E00h (11776 en décimal) et se terminant à 35F8h (13816 en décimal). Et nous nous souvenons, la taille du premier fichier était exactement de 11776 octets.

En conclusion: je pense que le fichier plus grand ne contient aucune information neuve. Mais je ne peux toujours pas répondre pourquoi le compilateur a ajouté 4 pages de données vides à la fin du fichier ProgramDataBase. Je pense que cette connaissance est un secret des développeurs du compilateur.

Answer 2

Le commentaire de Simon Mourier est presque certainement ce qui se passe. Lors du deuxième lancement du compilateur, le fichier PDB est mis à jour, et le résultat de cette mise à jour laisse des blocs 'supprimés' ou inutilisés à l'intérieur du PDB. Lors des constructions ultérieures, au lieu d'allouer de nouvelles pages pour les mises à jour, les pages inutilisées sont réutilisées (créant un autre ensemble de pages inutilisées dans le processus).

S'il existait un utilitaire pour 'collecter les déchets' du système de fichiers virtuel, vous finiriez probablement par obtenir un fichier de 12 Ko à nouveau.

Answer 3

Chaque compilation crée une nouvelle assembly différente.

Si vous souhaitez plonger dans les détails de ce qui est différent, alors vous voudrez peut-être consulter cet article : "piratage avec le clr : différenciation des assemblies".

Les éléments qui diffèrent entre les compilations :

• Horodatage
• no-ops
• GUID ModuleDef
• Attribut de débogage
• Second Horodatage
• PDB-GUID
• Différence de répertoire
• Plusieurs décalages de 4 octets (DataDirectory.Debug, SizeOFData, AddressOfRawData, PointerToRawData, DataDirectory.MetaData)

Je ne suis pas certain d'où provient la différence de taille supplémentaire de 2 ko entre la première et la deuxième compilation. Mais je pense qu'il pourrait y avoir des informations manquantes lors de la première construction mais ajoutées à chaque compilation ultérieure.