Visual Studio: отладочная информация в сборке выпуска
Мне очень хочется включить отладочную информацию в мои релизные сборки, которые отправляются клиентам. Насколько я понимаю, единственный недостаток - это увеличение размера двоичного файла на 25%. Преимущество в том, что я могу сразу же получить аварийный дамп, который намного легче анализировать. Я готов жить с увеличением на 25%. Есть ли другие недостатки, которые мне не хватает?
Это проект C, и все, что я хочу сделать, это связать / отладить / создать отладочную информацию
3 ответа
Размер исполняемого файла должен увеличиться гораздо меньше, чем на 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 и получающий ту же информацию о трассировке стека port-mortem.
Конечно, нужно помнить, что вам нужно архивировать файлы .pdb вместе с вашими релизами. Пакет «Средства отладки для Windows» (который теперь распространяется в Windows SDK) предоставляет инструмент сервера символов, который позволяет архивировать файлы .pdbs и легко извлекать их для отладки.
Единственный недостаток, который я могу придумать при распространении файлов .pdb, заключается в том, что это может упростить реверс-инжиниринг вашего приложения, если вас это беспокоит. Обратите внимание, что Microsoft распространяет символы для Windows (используя общедоступный сервер символов - а также пакеты полных наборов символов для некоторых конкретных выпусков). Однако символы, которые они распространяют, проходят этап очистки, который удаляет определенные элементы, которые они считают чувствительными. Вы можете сделать то же самое (или подобное), используя опцию компоновщика /PDBSTRIPPED ("Linker | Debugging | Strip Private Symbols" в IDE). См. документы MSDN для подробностей о том, что удаляет опция. Если вы собираетесь распространять символы, вероятно, уместно использовать эту опцию.
Вы не упоминаете, на каком языке вы находитесь, могут быть разные ответы для C ++ и C #.
Я не уверен на 100%, какие изменения вы собираетесь сделать. Собираетесь ли вы сказать Visual Studio, чтобы она выполняла стандартную отладочную компиляцию и отправляла ее, или вы собираетесь редактировать пару параметров в компиляции выпуска? Тщательное изменение настроек пары в сборке Release показалось мне лучшим подходом.
Что бы вы ни выбрали, я бы позаботился о том, чтобы оптимизации были включены, поскольку это может существенно повлиять на производительность скомпилированного кода.
Я всегда отправляю отладочную сборку, а не сборку выпуска. Я не могу думать ни о каких недостатках, а о преимуществах, как вы упоминаете.