У меня возникает соблазн включить отладочную информацию в мои выпуски, которые выходят клиентам. Насколько я вижу, единственная нижняя сторона - увеличение размера двоичного файла на 25%. Преимущество состоит в том, что я могу получить мгновенно используемый аварийный свал, гораздо легче проанализировать. Я готов жить с 25-процентным увеличением. Есть ли другие недостатки, которые я пропускаю?
Это проект C, и все, что я хочу сделать, это Linked/Debugging/Generate Debug Info
Размер исполняемого файла должен увеличиться гораздо меньше, чем на 25%.
Я на самом деле немного удивлен тем, что он вообще сильно увеличивается, но некоторые быстрые тесты показывают, что по крайней мере один большой пример проекта (ScummVM) увеличивает .exe с 10 205 184 байт до 10 996 224 байт, просто добавив опцию /DEBUG к ссылке. шаг (около 8%). /DEBUG указывается с помощью опции "Linker | Debugging | Generate Debug Info" в IDE. Обратите внимание, что эти настройки не должны влиять на оптимизации, генерируемые компилятором.
Я знаю, что указатель на файл .pdb помещен в исполняемый файл, но это не так уж и много. Я немного поэкспериментировал и обнаружил, что включение опции компоновщика /OPT:REF изменило разницу в размере до 10 205 184 против 10 205 696. Таким образом, сборка, отличная от /DEBUG, осталась на том же размере, но сборка /DEBUG уменьшилась только до 512 байт (что может быть учтено указателем на .pdb - возможно, компоновщик округляет до некоторого кратного 512 или чего-то еще).). Намного менее чем на 1% больше. По-видимому, добавление /DEBUG заставляет компоновщик сохранять объекты без ссылок, если вы также не укажете /OPT:REF. (Опция "Linker | Optimization | References" в IDE).
Программа будет работать без файла .pdb - вы можете отправить его клиентам, если вы хотите улучшить отладку на сайте клиента. Если вы просто хотите получить приличную трассировку стека, вам не нужно иметь файл .pdb на клиентском компьютере - они (или некоторые предоставляемые вами инструменты/функции) могут отправить файл дампа, который можно загрузить в отладчик на вашем сайте с доступным файлом .pdb и получающий такую же информацию о трассировке стека.
Конечно, следует помнить, что вам нужно архивировать файлы .pdb вместе с вашими выпусками. Пакет "Средства отладки для Windows" (который теперь распространяется в Windows SDK) предоставляет инструмент сервера символов, который позволяет архивировать файлы .pdb и легко извлекать их для отладки.
Единственный недостаток, который я могу придумать при распространении файлов .pdb, заключается в том, что это может упростить реверс-инжиниринг вашего приложения, если это вас беспокоит. Обратите внимание, что Microsoft распространяет символы для Windows (используя общедоступный сервер символов - а также пакеты полных наборов символов для некоторых конкретных выпусков). Однако символы, которые они распространяют, проходят этап очистки, который удаляет определенные элементы, которые они считают чувствительными. Вы можете сделать то же самое (или подобное), используя опцию компоновщика /PDBSTRIPPED ("Linker | Debugging | Strip Private Symbols" в IDE). См. документацию MSDN для получения подробной информации об удалении этой опции. Если вы собираетесь распространять символы, возможно, уместно использовать эту опцию.
В соответствии с документацией по Visual Studio 2005 в Документация по выбору Visual Studio 2005:
/DEBUG изменяет значения по умолчанию для параметра /OPT с REF на NOREF и от ICF до NOICF (поэтому вам нужно явно указать /OPT: REF или /OPT: ICF)
.В моем случае это помогло, когда я включил оба:
/O2 /DEBUG /OPT:REF /OPT:ICF
Вы не упоминаете на каком языке вы находитесь, и могут быть разные ответы для C++ и С#.
Я не уверен на 100%, какие изменения вы собираетесь сделать. Собираетесь ли вы сказать Visual Studio, чтобы она выполняла стандартную отладочную компиляцию и отправляла ее, или вы собираетесь редактировать пару параметров в компиляции выпуска? Тщательная модификация нескольких настроек в сборке выпуска кажется мне лучшим подходом.
Что бы вы ни делали в итоге, я бы позаботился о том, чтобы оптимизации были включены, поскольку это может существенно повлиять на производительность скомпилированного кода.
Я всегда отправляю сборку отладки, а не сборку релиза. Я не могу придумать никаких недостатков, и преимущества, как вы упоминаете.