[adventurer 0]

Здравствуйте,

может кто то из форумчан сталкивался с подобными проблемами. Я не так давно начал использовать Eclipse + GNU тулчейны для программирования ARM LPC2468. Для отладки начал использовать J-Link дебагер. Поискав в инете нашел описания как правильно настраивать и т.д. Для дебага использую yagarto gdb. Кристал нормально прошивается и работает, с брекпоинтамы вроде бы тоже все в норме, но на мой взгляд, как то странно ведет себя пошаговая отладка. В С листинге операции как то не по порядке исполняются, например, сначала подсвечивается строка 12, потом вместо следующего оператора со строки 13 переходит на 5, потом на 13. И есть сомнения по поводу корректности отображаемых текущих значений. В окне локальных переменных они меняются, даже если код их не изменяет. Код исполняется правильно, все работает, но вот только с пошаговой отладкой как то не получилось до конца разобраться. Может ли иметь значения, что для компиляции я использую другой тулчейн, а для отладки yagarto ? Пошаговая отладка это конечно не так критично для меня, но все же таки очень бы хотелось разобраться и услышать об опыте использования подобной комбинации J-Link + GNU от гуру, какие проблемы и чего стоить опасаться.

[Spym 0]

В С листинге операции как то не по порядке исполняются<...>

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

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

Передайте компилятору ключ -O0.

Изменено 17 марта, 2011 пользователем Spym

[Сергей Борщ 141]

Передайте компилятору ключ -O0.

И будете отлаживать совершенно другой код.

 

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

 

[Spym 0]

<...>оптимизатор использует один кусок кода в этих строках совместно. Возможно он поменял местами некоторые операции для уменьшения размера или увеличения скорости полученного кода. Ну и порой<...>

О чем и речь.

Оптимизация препятствует удобству символьной отладки, Вы ведь не будете с этим спорить.

[Сергей Борщ 141]

Оптимизация препятствует удобству символьной отладки, Вы ведь не будете с этим спорить.

Не буду. Но смысл в удобстве отладки другого кода? Это как искать ключ не там где потерял, а под фонарем, потому что там светлее. Вы не выловите ни ошибок из-за пропущенных volatile, ни ошибок связанных со скоростью выполнения отдельных участков кода, ни ошибок переполнения стека.

 

[GetSmart 0]

Но всё-таки, если есть ошибка (большинство из них) в коде, то она найдётся. 90% ошибок. Но не 100.

[adventurer 0]

И будете отлаживать совершенно другой код.

 

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

 

Я посмотрел на дисасемблинг, честно говоря не могу до конца разобраться какой С код ответствует какому ассемблерному. Например при пошаговой отладки в С-ном коде внутри цыкла переходим только по строкам 904 потом на 903 потом переходим на следующую итерацию цикла и не попадая на 905.

 

 

 

 

 

 

Интересует если кто то пользуется пошаговой отладкой, это не так критично, ибо не очень часто пользуюсь, но в некоторых вещах может бить полезно, хотелось бы разобраться. Может причина в параметрах компиляции для подключения символьной информации, я использую –ggdb, пробовал просто –g, но результат аналогичен?

 

 

 

 

[Сергей Борщ 141]

Я посмотрел на дисасемблинг, честно говоря не могу до конца разобраться какой С код ответствует какому ассемблерному. Например при пошаговой отладки в С-ном коде внутри цикла переходим только по строкам 904 потом на 903 потом переходим на следующую итерацию цикла и не попадая на 905.

Дело в том, что "!" по адресу 75ac и есть ваша строка 905, в то время как вся команда - строка 903.

[adventurer 0]

Дело в том, что "!" по адресу 75ac и есть ваша строка 905, в то время как вся команда - строка 903.

Спасибо за подсказку, многому еще надо учиться. Но мне все же интересно, это проблема с пошаговой отладкой и оптимизацией, только для конкретного случая, или это типично для Eclipse + gdb. Раньше использовал Keil для 51 микроконтроллеров, такой ситуации не наблюдал ?

[Сергей Борщ 141]

это проблема с пошаговой отладкой и оптимизацией, только для конкретного случая, или это типично для Eclipse + gdb.

Для любого оптимизирующего компилятора.

Раньше использовал Keil для 51 микроконтроллеров, такой ситуации не наблюдал ?

Не включали оптимизацию? Еще в Кейле версии 2.51 оптимизатор работал так, что исходный код узнать было трудно.

 

[adventurer 0]

Да, оптимизатор действительно выключал, только что проверил :rolleyes:

Спасибо за объяснения, пожалуй слишком много я ожидал от пошаговой отладки, что можно спокойно идти по коду не прибегая к пониманию ассемблера. Но теперь хоть точно знаю что причина не в кривом прикручивании тулзов или дебагера.