Каковы последствия использования / Zi vs / Z7 для проектов Visual Studio C ++? - PullRequest
34 голосов
/ 12 ноября 2008

Фон

Существует несколько различных флагов отладки , которые можно использовать с компилятором Visual Studio C ++. Это:

  • (нет)
    • Создать без отладочной информации
    • Более быстрое время компиляции
  • / Z7
    • Создание полносимвольной отладочной информации в файлах .obj с использованием формата CodeView
  • / Zi
    • Создание полносимвольной отладочной информации в файле .pdb для цели с использованием формата базы данных программы.
    • Включает поддержку минимальной перестройки (/ Gm), которая может сократить время, необходимое для перекомпиляции.
  • / ZI
    • Создание отладочной информации, такой как / Zi, за исключением поддержки Edit-and-Continue

Вопросы

  • Флаг / Gm несовместим с флагом / MP для сборок с несколькими процессами (Visual Studio 2005/2008)

  • Если вы хотите включить минимальное перестроение, то необходимо установить флаг / Zi поверх флага / Z7.

  • Если вы собираетесь использовать флаг / MP, по-видимому, нет никакой разницы между / Z7 и / Zi, смотрящими на MSDN. Однако в документации SCons указано, что вы должны использовать / Z7 для поддержки параллельных сборок.

Вопросы

  • Каковы последствия использования / Zi vs / Z7 в проекте Visual Studio C ++?

  • Есть ли другие плюсы или минусы для любого из этих вариантов, которые я пропустил?

  • В частности, каково преимущество одного файла формата программной базы данных (PDB) для цели по сравнению с несколькими файлами формата CodeView (.obj) для каждого источника?

Ссылки

MDSN / Z7, / Zi, / ZI (формат информации отладки)

MSDN / MP (сборка с несколькими процессами)

Переменные конструкции SCons CCPDBFLAG

Отладочная информация

Ответы [ 5 ]

8 голосов
/ 14 ноября 2008

Codeview - гораздо более старый формат отладки, который был введен со старым автономным отладчиком Microsoft еще во времена "компилятора Microsoft C" в середине 1980-х годов. Он занимает больше места на диске и анализируемому отладчику занимает больше времени, и это большая проблема для обработки во время компоновки. Мы сгенерировали его из нашего компилятора еще во время работы над CodeWarrior для Windows в 1998-2000 годах.

Единственным преимуществом является то, что Codeview является документированным форматом, и другие инструменты часто могут его обрабатывать, когда им не удается справиться с отладочными базами данных в формате PDB. Кроме того, если вы создаете несколько файлов одновременно, нет необходимости спорить о записи в базу данных отладки для проекта. Однако для большинства случаев использования формат PDB является большой победой как во время сборки, так и особенно во время запуска отладчика.

7 голосов
/ 14 ноября 2008

Одним из преимуществ старого формата C7 является то, что он все-в-одном, хранится в EXE, а не в отдельной PDB и EXE. Это означает, что вы никогда не можете иметь несоответствие. Инструменты разработчика VS будут проверять соответствие PDB своему EXE-файлу до того, как будут его использовать, но, безусловно, проще иметь один EXE-файл со всем необходимым.

Это добавляет новые проблемы, связанные с необходимостью извлечения отладочной информации при выпуске, и гигантского EXE-файла, не говоря уже о древнем формате и отсутствии поддержки других современных функций, таких как minrebuild, но все же может быть полезным, когда Вы пытаетесь сделать вещи максимально простыми. Один файл проще, чем два.

Не то чтобы я когда-либо использовал формат C7, я просто выкладываю это как возможное преимущество, поскольку вы спрашиваете.

Кстати, именно так GCC работает на паре платформ, которые я использую. Формат DWARF2 похоронен в выходных ELF. Люди Unix думают, что они такие веселые. :)

Кстати, формат PDB может быть проанализирован с использованием DIA SDK .

3 голосов
/ 12 июля 2012

Есть еще один недостаток для / Z7: Он не совместим с инкрементными ссылками, что само по себе может быть причиной, чтобы этого избежать. Ссылка: http://msdn.microsoft.com/en-us/library/4khtbfyf%28v=vs.100%29.aspx

Кстати: несмотря на то, что Microsoft говорит, что полная ссылка (а не инкрементная) выполняется, когда «объект, скомпилированный с параметром / Yu / Z7, изменен», похоже, это верно только для статических библиотек сборка с / Z7, не для объектных файлов.

1 голос
/ 05 февраля 2019

/Z7 сохраняет отладочную информацию в файлах .obj в формате CodeView и позволяет компоновщику извлекать их в файл .pdb, тогда как /Zi объединяет его в общий файл .pdb, синхронизируя его с mspdbsrv.exe во время компиляции. .

То есть /Z7 означает больше файлового ввода-вывода, используемого дискового пространства и больше работы для компоновщика, поскольку в этих файлах obj имеется много дублирующейся отладочной информации. Но это также означает, что каждая компиляция независима и, таким образом, может все же быть быстрее, чем /Zi с достаточным распараллеливанием.

К настоящему времени они улучшили ситуацию /Zi, уменьшив межпроцессное взаимодействие с mspdbsrv.exe: https://docs.microsoft.com/en-us/cpp/build/reference/zf

Другой вариант использования /Z7 предназначен для «автономных» (хотя и более крупных) статических библиотек, которые не требуют доставки отдельной .pdb, если вы этого хотите. Это также предотвращает раздражающие проблемы, возникающие из-за ужасного использования по умолчанию vcxxx.pdb name cl, если вы не исправите это с помощью правильного https://docs.microsoft.com/en-us/cpp/build/reference/fd-program-database-file-name,, о котором большинство людей забывают.

/ZI аналогичен /Zi, но добавляет дополнительные данные и т. Д. Для работы функции «Редактировать и продолжить».

1 голос
/ 26 января 2016

Другим недостатком / Z7 является большой размер объектных файлов. Это уже упоминалось здесь, однако это может перерасти до того момента, когда компоновщик не сможет связать исполняемый файл, поскольку он нарушает ограничение размера компоновщика или формата PE (это дает вам ошибку компоновщика LNK1248). Кажется, Visual Studio или формат PE имеет жесткое ограничение в 2 ГБ (также на компьютерах x64). При создании отладочной версии вы можете столкнуться с этим ограничением. Похоже, что это влияет не только на размер конечного скомпилированного исполняемого файла, но и на временные данные. Только Microsoft знает о внутренних компонентах компоновщика, но мы столкнулись с этой проблемой здесь (хотя исполняемый файл был, конечно, не 2-гигабайтным, даже в отладочном режиме). Проблема чудесным образом ушла и никогда не возвращалась, когда мы переключили проект на /ZI.

...