Оптимизация может влиять на способность отладить VC ++ приложение с помощью его PDB?

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

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

5
задан SamB 14 April 2010 в 21:35
поделиться

4 ответа

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

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

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

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

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

7
ответ дан 18 December 2019 в 14:52
поделиться

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

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

2
ответ дан 18 December 2019 в 14:52
поделиться

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

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

2
ответ дан 18 December 2019 в 14:52
поделиться

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

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

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

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

2
ответ дан 18 December 2019 в 14:52
поделиться