Как узнать, был ли исполняемый файл инкрементально связан или нет?

Я пытаюсь использовать Purify 6 для анализа повреждения памяти в одном из наших исполняемых файлов, созданных с помощью VC++ 2003 (7.1).Как узнать, был ли исполняемый файл инкрементально связан или нет?

Когда инструмент двоичная с помощью следующей команды:

purify /Replace=yes /Run=no myprog.exe

Инструментовка прекращает говорить мне исполняемый файл был постепенно связаны между собой. Озадаченный, я проверил варианты сборки, но /INCREMENTAL:NO был там. Разумеется, я перестроил его, и этот вариант был правильно передан во время соединения.

Есть ли способ узнать, является ли исполняемый файл инкрементным соединением или нет?

Я посмотрел, что dumpbin /HEADERS говорит, но ничего не видел.

Спасибо.

источник

2009-07-07 bltxd

Я думаю, что инкрементированный исполняемый файл может быть больше обычного. – ChrisW

Они конечно могут, но зная, что это мне не помогает. – bltxd

Вы пытаетесь отлаживать или выпускать exe? Потому что «/ INCREMENTAL подразумевается, когда указано/DEBUG» (http://msdn.microsoft.com/en-us/library/4khtbfyf.aspx). – Kcats

Вариант 1:

с: ...> DUMPBIN/резюме whatever.exe

Посмотрите на раздел ".textbss".

Я не уверен, что это на 100% надежна, но по моему опыту линкер всегда добавляет этот раздел при инкрементном соединении.

Вариант 2:

Посмотрите на файл ".ilk" рядом с исполняемым файлом. Visual Studio, похоже, хорошо разбирается в них, когда они не используются, поэтому отключить инкрементную привязку и создание (даже не «перестроить») следует удалить.

Вариант 3:

Включить сборку входа (Tools/Options/Проекты) и искать "/ инкрементный" или "/ INCREMENTAL: NO" в файле buildlog.html, который он создает.

Вариант 4:

Разбираем файл .vcproj. (ick!)

источник

2009-07-13 18:18:55

Что касается очистки в варианте 2: вы можете быть правы, но ссылка MSDN в моем комментарии, похоже, указывает на другое. (Я думаю, что вариант 3 был фактически упомянут в самом вопросе, подтвердив команду сборки.) – Arjan

Спасибо за ввод. Я собираюсь проверить пункт 1 сразу. Остальные моменты немного сбиты, поскольку я контролирую процесс сборки (здесь нет .vcproj), и мне просто нужен способ убедиться, что доставленный двоичный код не был поэтапно связан по ошибке.Процесс сборки не устанавливает файлы .ilk в любом случае. – bltxd

Если вы доставляете двоичные файлы, то лучший способ - построить их из чистой проверки (на специализированной машине сборки с контролируемой средой). Это устранит эту и многие другие потенциальные проблемы. – Eugene

Как узнать, был ли исполняемый файл инкрементально связан или нет?

ответ

Смежные вопросы