Оптимизация может влиять на способность отладить VC ++ приложение с помощью его PDB?
Для некоторых людей покрытие - это просто «то, что инструмент, который мы используем, сообщает в качестве покрытия», но если это то, что вы ищете, вам сначала нужно будет объяснить, какой вид покрытия использует используемый вами инструмент.
Предполагая, что используемый вами язык имеет краткую оценку условных выражений, два разных способа написания имеют одинаковое значение. Следовательно, для одного и того же набора тестов покрытие операторов, покрытие филиалов, покрытие условий и т. Д. Будут одинаковыми. Если вы посмотрите на некоторые нетипичные виды покрытия (например, покрытие линий), могут быть различия.
Если вы намерены тщательно протестировать свой код, вам следует создать один и тот же набор тестов, независимо от того, какой из двух способов вы используете для написания кода. Однако тогда вам не следует сосредотачиваться только на покрытии: выражения в вашем коде должны будут выполняться различными способами, проверяя граничные случаи. Следует учитывать отношения потоков данных между производителями и потребителями, и многое другое ...
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 мог бы обработать некоторые из этих случаев лучше.
Да. Это может время от времени быть серьезно, хотя это - обычно больше результат встраивания или переупорядочения кода.
Локальные переменные также не могут быть точно отображены в окне часов, как они могут только существовать в регистрах и не могут быть правильно отображены когда Вы кадры стека коммутаторов.
В дополнение к локальным переменным 'этот' указатель обычно оптимизируется далеко в оптимизированных сборках. Это может иногда работаться вокруг путем восстановления работоспособности достаточно в стеке вызовов до такой степени, когда, объектный указатель или ссылка существуют как not-optimized-away переменная.
В целом. единственное продвижение в оптимизированной сборке обычно работает более или менее и позволяет для наблюдения, какие логические решения код принимает. Исследование данных, на которых базируются эти решения, обычно намного более сложно.
Оптимизация может сильно повлиять на отладку на любую платформу (не только файлы VC PDB).
Точно по причинам Вы упомянули, функциональное встраивание может в некоторых случаях полностью перепутать, какие инструкции принадлежат, к которой функции (так как иногда они сортируют, принадлежат обоим).
Также общая оптимизация должна сделать "грязные" стековые фреймы (-fomit-frame-pointer в GCC), который заставляет код не отслеживать вершину стека. Это прекрасно, это освобождает дополнительный регистр (ebp на x86) для других операций. Но это делает почти невозможным раскрутить стек для наблюдения то, что на самом деле продолжается. Это также делает почти невозможным найти локальные переменные и параметры функции на стеке.
В целом: не ожидайте вытаскивать полезную отладочную информацию из сборок "выпуска". Если отладка настолько важна, даже на выпуске, то необходимо "выпускать" сборки отладки вместо этого.