Я еще долго не делал C ++, но из этой статьи , похоже, что это трюк производительности, чтобы остановить воспроизведение символов для общих заголовков.
Вы можете попробовать / Z7 вставлять информацию в каждый объект, а не создавать PDB, а затем связывать и воссоздавать его с помощью rebase, как в этой статье .
Не нужно объединять файлы PDB.
Скомпилировать исходные файлы с помощью / Z7, чтобы избежать создания PDB во время шагов CL.EXE.
Использовать LIB.EXE для создания статических библиотек с встроенной информацией отладки. Используйте LINK.EXE вместо CL.EXE для связи, используйте / PDB, чтобы указать, куда будет выводиться информация об отладке.
Если вы отлаживаете процесс с EXE и одной или несколькими DLL, отправьте отладчик PDB для каждого изображения (EXE или DLL).
Если вы не хотите перераспределять статические библиотеки с информацией об отладке, вам фактически не нужно объединять любые файлы PDB (или использовать /Z7
для встраивания информации об отладке).
Как упоминал @zhaorufei, при использовании /Zi
каждый объектный файл содержит ссылку на свой файл PDB, который затем использует компоновщик.
Просто используйте /Fd
чтобы дать каждому объекту уникальный файл PDB:
> 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
Это также имеет то преимущество, что оно работает вокруг проблем одновременного доступа к общим файлам PDB, упомянутым здесь здесь , поэтому вы можете параллельный шаг компиляции, как вы хотели.
Затем свяжите / архивируйте объектные файлы, как обычно. VC ++ уже внедряет различные типы информации в объектных файлах, чтобы передать их компоновщику, например, настройку ссылки времени выполнения и библиотеки зависимостей - путь к файлу PDB не отличается. Создание статической библиотеки из объектов не удаляет ссылки:
> 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
При связывании этой библиотеки с исполняемым файлом или DLL компоновщик по-прежнему извлекает информацию об отладке из связанных PDB и добавляет ее в окончательный файл PDB.
Единственное предостережение, которое я вижу, это то, что путь всегда абсолютен, поэтому это может не сработать, если вы перемещаете файлы локально или на другую машину перед связыванием.
Слияние файлов PDB возможны, но могут выполняться только cl.exe и link.exe. Я не знаю каких-либо отдельных инструментов для объединения файлов PDB.
Вы можете использовать опцию / PDB для компоновщика (я проверил VC2005), чтобы указать альтернативное имя файла pdb.
Microsoft предлагает также включают файлы PDB (каждый obj имеет соответствующий файл PDB) вместе с файлом .LIB.
Вы не можете архивировать файлы PDB внутри .LIB-файла, я пробовал его с VC2003, не удалось.
Компиляция с / Z7 может избежать файлов PDB для .LIB, но объектные файлы большие, если link.exe не отделяет отладочную информацию. Если у вас нет опции / debug для компоновщика, то ваш exe / dll не может быть отлажен.
Компилятор (cl.exe) всегда записывает файл vcXX.pdb, если вы не используете параметр / Fd для указания другого имени. Даже когда вы используете cl.exe для создания исполняемого файла «напрямую», он создаст файл vc80.pdb, а затем файл link.exe будет вызывать имя файла pdb, аналогичное исполняемому.
cl / Zi test.c
cl.exe -> vc80.pdb link.exe read vc80.pdb (имя встроено в файл test.obj) -> test.pdb
Каждый time cl / Zi / c скомпилировать файл, он попытается изменить существующий файл vcXX.pdb, а не перезаписывать его.
Я получил вышеупомянутое соглашение путем игры с компилятором снова и снова, а затем захват sceinternals's procexp и проанализировать его. Надеюсь, что это поможет.