Могут ли оптимизации повлиять на возможность отладки приложения VC ++ с использованием его PDB?

Question

Для правильной отладки сборок релиза необходим файл PDB. Может ли файл PDB стать менее пригодным для использования, когда компилятор использует различные виды оптимизации (FPO, PGO, встроенные функции, встраивание и т. Д.)? Если да, то является ли эффект оптимизации серьезным или просто вызывает перепутывание смежных строк кода?

(я использую VC2005 и всегда буду выбирать отлаживаемость вместо оптимизированной производительности - но вопрос общий)

Answer 1

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

Самая большая проблема, на мой взгляд, это локальные переменные. Компилятор может использовать один и тот же адрес стека или зарегистрироваться для нескольких переменных в функции. Как упоминалось в других постерах, иногда даже выяснение, что такое указатель "this", может занять некоторое время. При отладке оптимизированного кода вы можете увидеть текущую строку, скачущую за один шаг, поскольку компилятор реорганизовал сгенерированный код. Если вы используете PGO, этот прыжок, скорее всего, только ухудшится.

FPO не должен слишком сильно влиять на возможность отладки, если у вас есть PDB, поскольку PDB содержит всю информацию, необходимую для размотки стека для кадров FPO. FPO может быть проблемой при использовании инструментов, которые должны выполнять трассировку стека без символов. Для многих проектов преимущество FPO в настоящее время не превышает возможности диагностики; по этой причине MS решила не собирать Windows Vista с оптимизацией FPO (http://blogs.msdn.com/larryosterman/archive/2007/03/12/fpo.aspx).

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

Это все относится к windbg, так как я делаю с ним отладку всего нативного кода. Отладчик Visual Studio может лучше обрабатывать некоторые из этих случаев.

Answer 2

Оптимизация может серьезно повлиять на отладку на любой платформе (не только файлы PDB VC).

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

Также обычной оптимизацией является создание «грязных» кадров стека (-fomit-frame-pointer в GCC), что приводит к тому, что код не отслеживает вершину стека. Это нормально, это освобождает дополнительный регистр (например, на x86) для других операций. Но практически невозможно раскрутить стек, чтобы увидеть, что на самом деле происходит. Это также делает почти невозможным поиск локальных переменных и параметров функций в стеке.

В целом: не ожидайте получить полезную отладочную информацию из сборок "release". Если отладка так важна даже при выпуске, вы должны вместо этого «выпускать» отладочные сборки.

Answer 3

В дополнение к локальным переменным указатель 'this' обычно оптимизируется в оптимизированных сборках. Иногда это можно обойти, поднявшись достаточно в стеке вызовов до точки, где указатель объекта или ссылка существуют как неоптимизированная переменная.

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

Answer 4

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

Локальные переменные также могут не отображаться точно в окне просмотра, поскольку они могут существовать только в регистрах и могут отображаться некорректно при переключении кадров стека.