c# - print - Archivo PDB más grande en la segunda compilación y luego permanece del mismo tamaño

print c#

Question

Usando el siguiente archivo simple:

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

Y luego usando el siguiente comando:

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

Si ejecuta este comando y el PDB no existe ya, entonces el tamaño del archivo PDB es 12KB. De lo contrario, si el archivo PDB existe, entonces el nuevo tamaño del archivo es de 14 KB.

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

Alguien tiene alguna idea de lo que explicaría esto?

ACTUALIZAR:

1. No experimento esto con .NET 3.5 y de los comentarios .NET 4 tampoco.
2. Al usar pdb2xml ( http://blogs.msdn.com/b/jmstall/archive/2005/08/25/sample-pdb2xml.aspx ), no puedo ver ninguna diferencia entre el pequeño y el más grande.

Answer 1

Cada compilación crea un nuevo conjunto diferente .

Si desea profundizar en qué es exactamente lo que es diferente, puede echarle un vistazo a este artículo: " hackear con el clr: ensamblajes diferenciales ".

Cosas que difieren entre compilaciones:

• Marca de tiempo
• no-ops
• ModuleDef GUID
• Atributo de depuración
• Segunda marca de tiempo
• PDB-GUID
• Diferencia de directorio
• Varios Offset de 4 bytes (DataDirectory.Debug, SizeOFData, AddressOfRawData, PointerToRawData, DataDirectory.MetaData)

No estoy seguro de dónde proviene la diferencia de tamaño adicional de 2 kb entre la primera y la segunda compilación. Pero supongo que puede haber cierta información que no se incluye durante la primera compilación, pero se agrega en cada compilación posterior.

Answer 2

El comentario de Simon Mourier es casi ciertamente lo que está pasando. En la segunda ejecución del compilador, el archivo PDB se actualiza, y el resultado de esa actualización deja los bloques ''eliminados'' o no utilizados dentro de la PDB. En las compilaciones posteriores, en lugar de asignar nuevas páginas para las actualizaciones, las páginas no utilizadas se reutilizan (creando otro conjunto de páginas no utilizadas en el proceso).

Si hubiera una utilidad para ''recolectar basura'' el sistema de archivos virtual, probablemente terminaría con un archivo de 12KB nuevamente.

Answer 3

Mi respuesta es simple, pero tal vez no tan precisa. Usemos una herramienta de depuración en nuestros archivos PDB:

La única diferencia es el campo PdbAge . Esto significa que el archivo PDB no se vuelve a crear después de cada compilación. Este archivo es modificado, es por eso que cambia de tamaño.

Mi conjetura se confirma en este article . Citar:

Una de las motivaciones más importantes para el cambio de formato fue permitir el enlace incremental de las versiones de depuración de los programas, un cambio introducido por primera vez en Visual C ++ versión 2.0.

Otra pregunta es ¿qué se cambia exactamente en este archivo? La explicación más detallada sobre el formato de archivo que he encontrado en el libro " Sven B. Schreiber," Los secretos sin documentar de Windows 2000: Un libro de cocina del programador " ". La frase clave es:

Un beneficio aún mayor del formato PDB se hace evidente al actualizar un archivo PDB existente. Insertar datos en un archivo con una estructura secuencial por lo general significa reorganizar grandes porciones de los contenidos. La estructura de acceso aleatorio del archivo PDB tomada de los sistemas de archivos permite agregar y eliminar datos con un mínimo esfuerzo, al igual que los archivos se pueden modificar con facilidad en un medio del sistema de archivos. Solo se debe reorganizar el directorio de flujo cuando un flujo crece o se contrae a través de un límite de página. Esta importante propiedad facilita la actualización incremental de los archivos PDB.

Describe que no todos los datos en archivo son útiles en todo momento. Algunos rangos de bytes se rellenan simplemente con ceros hasta que ese archivo se modifique durante la próxima compilación.

Por lo tanto, no puedo saber qué se cambió exactamente en el archivo PDB, excepto algunos GUID y el número de edad. Puedes profundizar después de leer ese libro. ¡Buena suerte!

ACTUALIZACIÓN (15/03/2013):

Pasé un poco más de tiempo para comparar archivos. Cuando los abro en modo HEX, veo las diferencias en el encabezado: El tamaño de la página del archivo es de 512 bytes (valor de 200h a + 20h) y el recuento de páginas es diferente: 120 y 124 (078h y 07Ch en consecuencia). En mis pantallas el archivo más pequeño está en el lado izquierdo. DE ACUERDO. La diferencia en el tamaño del archivo es exactamente 2048 bytes. Significa que el compilador agrega 4 páginas de datos a la segunda vez. Entonces encontré todas las demás diferencias. 3/4 del archivo desde el principio contiene pequeñas diferencias, algunos bytes como de costumbre. Pero en el punto 2600h vemos:

¡Mira! La línea /LinkInfo./names./src/files/c:/Windows/microsoft.net/framework/v4.0.30319/helloworld.cs se recorta y ahora contiene información inconsistente.

Espero y encontré esta línea en el segundo archivo (más grande) en representación completa: Esta información se colocó para liberar espacio ahora (ver ceros en el lado izquierdo). Supongo que las páginas antiguas (con una cadena dañada) se marcaron como espacio no utilizado.

Y al final del archivo he encontrado exactamente 2048 bytes de nueva información, todos son ceros. Comenzando a las 2E00h (11776 en decimal) y terminando a las 35F8h (13816 en decimal). Y recordamos, el tamaño del primer archivo era exactamente 11776 bytes.

Como conclusión: creo que el archivo más grande no contiene ninguna información nueva . Pero todavía no puedo responder por qué el compilador agregó 4 páginas de datos vacías al final del archivo ProgramDataBase. Creo que este conocimiento es un secreto de los desarrolladores de un compilador.