Visual Studio: отладочные сведения в сборке выпуска
У меня возникает соблазн включить отладочную информацию в мои сборки выпуска, которые выходят для клиентов. Насколько я вижу, единственным недостатком является увеличение размера двоичного файла на 25%. Преимущество в том, что я могу получить сразу же полезный аварийный дамп, гораздо проще анализировать. Я готов жить с увеличением на 25%. Есть ли другие недостатки, которые я упускаю?
Это проект C, и все, что я хочу сделать, это связать / отладка / генерировать отладочную информацию
4 ответов
размер исполняемого файла должен увеличиваться намного меньше, чем на 25%.
Я на самом деле немного удивлен, что он значительно увеличивается, но некоторые быстрые тесты показывают, что по крайней мере один большой пример проекта (ScummVM) увеличивает .exe от 10,205,184 байт до 10,996,224 байт, просто добавив /DEBUG опция для шага ссылки (около 8% увеличения). /DEBUG задается с помощью "Linker | Debugging | Generate Debug Info" опция в IDE. Обратите внимание, что это настройки должны нет эффекта об оптимизациях, генерируемых компилятором.
Я знаю, что указатель на .pdb-файл помещается в исполняемый файл, но это не так много. Я немного поэкспериментировал и обнаружил, что включение /OPT:NOREF опция компоновщика изменила разницу в размере на 10,205,184 против 10,205,696. Так что не /DEBUG build остался того же размера, но /DEBUG build упал только до 512 байт больше (что может быть учтено указателем на-.pdb-возможно, раунды компоновщика для некоторых кратных 512 или что-то в этом роде). Гораздо меньше, чем 1% прироста. Видимо, добавляя /DEBUG заставляет компоновщик сохранять объекты без ссылок, если вы также не укажете /OPT:NOREF. ("Linker | Optimization | References" опция в IDE).
программа будет работать нормально, без .pdb-файл-вы можете отправить его клиентам, если хотите обеспечить лучшую отладку на сайте клиента. Если вы просто хотите иметь возможность получать приличные трассировки стека, вам не нужно их иметь .pdb-файл на компьютере клиента-они (или какой инструмент/функции) можно отправить файл дампа, который может быть загружен в отладчик на вашем сайте .pdb-файл доступен и получает ту же информацию о трассировке стека port-mortem.
одна вещь, конечно, быть в курсе, что вам нужно будет архивировать .pdb файлы вместе с вашими релизами. Пакет "средства отладки для Windows" (который теперь распространяется в Windows SDK) предоставляет средство сервера символов, чтобы вы могли архивировать .pdbs и легко получить их для отладка.
единственный недостаток, который я могу придумать для распространения .pdb-файлы - это то, что он может упростить обратное проектирование вашего приложения, если это вас беспокоит. Обратите внимание, что Microsoft распространяет символы для Windows (используя сервер открытых символов, а также пакеты полных наборов символов для некоторых конкретных выпусков). Однако символы, которые они распространяют, проходят через этап дезинфекции, который удаляет определенные элементы, которые они считают чувствительными. Вы можете сделать то же самое (или похожие) с помощью компоновщика ("Linker | Debugging | Strip Private Symbols" в IDE). См.документы MSDN для получения подробной информации о том, что опция удаляет. Если вы собираетесь распространять символы, вероятно, целесообразно использовать эту опцию.
в соответствии с документацией VS2005 на http://msdn.microsoft.com/en-us/library/xe4t6fc1(в=против 80).аспн:
/ DEBUG изменяет значения по умолчанию для параметра /OPT с REF на NOREF и от ICF до NOICF (таким образом, вам нужно будет явно указать /OPT:REF или / OPT: ICF).
в моем случае это помогло, когда я позволил как:
/O2 /DEBUG /OPT:REF /OPT:ICF
вы не упоминаете, на каком языке вы находитесь, могут быть разные ответы на C++ и c#.
Я не на 100% уверен, какие изменения вы планируете сделать. Собираетесь ли вы сказать Visual Studio сделать стандартную отладочную компиляцию и отправить ее, или вы собираетесь отредактировать пару параметров в компиляции выпуска? Тщательная модификация пары настроек в сборке релиза поражает меня как лучший подход.
независимо от того, что вы в конечном итоге, я бы убедился, что оптимизация включена, так как это может существенно повлиять на производительность скомпилированного кода.
Я всегда отправляю отладочную сборку, а не сборку выпуска. Я не могу думать о каких-либо недостатках, и преимущества, как вы упомянули.