Сборка Visual C++ 2008 'Release' содержит отладочную информацию

Я заметил, что при создании нового проекта C++ с помощью MS Visual Studio 2008 сборка Выпускать содержит символы отладки - в частности, включены следующие параметры:

  • Формат C++ / General / Debug Information Format установлен на База данных программы.
  • Параметр Linker / Debugging / Generate Debug Info установлен на да.

Я никогда не замечал этого в более ранних выпусках Visual Studio.

Итак, есть ли какие-либо недостатки в том, чтобы оставить эти настройки включенными, кроме создания более крупного EXE-файла?

Пожалуйста, уточните, действительно ли у вас есть EXE-файлы большего размера или (если, как предлагает Дэйв Ван ден Эйнде) вся дополнительная информация будет отправляться в файл PDB.

Adam Mitz 21.10.2008 03:20

Это верно и для VC10 ...

Gob00st 15.12.2012 21:08
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
17
2
10 312
6
Перейти к ответу Данный вопрос помечен как решенный

Ответы 6

Что ж, вы можете предоставить эту отладочную информацию, и кто-то может использовать ее для дизассемблирования вашего кода. Для некоторых напуганных людей это само по себе может быть причиной не оставлять это таким образом.

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

Эти параметры не обязательно увеличивают размер ваших исполняемых файлов. Отладочная информация хранится в отдельном файле с расширением PDB. Наличие отладочной информации никогда не является плохой идеей, если вам действительно не хватает свободного места для хранения.

Возможно, поэтому они включены по умолчанию: они не вредят вашим исполняемым файлам. В сборках выпуска используются такие оптимизации, как встраивание функций и генерация оптимизированного кода, что затрудняет пошаговое выполнение, в то время как в сборках отладки эти параметры отключены.

Здесь нет недостатков.

Дэйв

Ответ принят как подходящий

Мы уже много лет включаем эти настройки в наших коммерческих выпусках без видимых недостатков. Однако положительные стороны огромны.

Мы интегрировали упаковщик аварийного дампа, который упаковывает дамп вместе с некоторой другой информацией и отправляет его (с согласия пользователя) в почтовый ящик компании. Это помогло нам найти проблемы, на воспроизведение которых потребовалось бы навсегда, и найти их иначе.

Хотя это немного не по теме, вот ссылка на отличный вклад, сделанный кем-то, который дает вам простой способ включить репортер сбоев в приложение C++ / Windows: http://www.codeproject.com/KB/debug/crash_report.aspx

Примечание. Было бы разумно не включать файл PDB в ваш выпуск. Тем не менее, вы должны сохранить файл PDB, который соответствует вашей выпущенной версии, чтобы вы могли правильно отладить проблему в будущем. Если используется файл PDB, который не был создан с использованием того же кода, что и для exe, стек, который вы видите при попытке отладки dmp, будет неправильным.

На аналогичный вопрос несколько лет спустя следующий ответ дал еще несколько подробностей: stackoverflow.com/a/6364789/2937955 (см. Интересное примечание о реверс-инжиниринге и опции / PDBSTRIPPED)

FlorianT 18.11.2016 15:56

.Exe будет немного больше из-за ссылки на файл .pdb (т. Е. Дополнительного пути). Вот об этом.

Добавление переключателя / Zi делает файл .exe большего размера в дополнение к PDB. Однако вы можете установить отдельную ссылку с помощью / OPT: REF, чтобы минимизировать размер файла .exe.

В Visual Studio 2008 этот параметр находится в разделе «Свойства-> Компоновщик-> Оптимизация-> Ссылки». Вы также можете рассмотреть возможность включения «Включить COMDAT Folding», который также уменьшит двоичный размер.

John 03.04.2009 21:43

По умолчанию они включены, потому что:

  1. Если вы не создадите их сейчас, вы не сможете создать их позже.
  2. Они вам нужны.

Включение отладочной информации в Visual C++ приводит к добавлению небольшой записи в двоичный заголовок, идентифицирующей PDB для этого двоичного файла. Он слишком мал, чтобы иметь какое-либо значение, и не содержит каких-либо полезных секретов, которыми вы, возможно, захотите поделиться.

(Заголовок помечен как RSDS: кто может догадаться, почему?)

Конечно, эти PDB будут использовать больше дискового пространства на вашей машине сборки / в ваших резервных копиях. Смирись с этим. Эти PDB нужны, когда приходит время что-то отлаживать.

Другие вопросы по теме