Откуда такие сведения? Т.е. вам приходилось отлаживать код release? И все работало?


Сейчас слегка изучил возможности отладки из под CDT 8.0 :
1. Точки останова только на код с возможностью "наложить" на них действия: выдать звук, продолжить программу через заданное время в сек., выдать лог (текстовый и выполнить некоторый набор инструкций), выполнить некую внеш утилиту. Мне непонятны две вещи: если в качестве лога предлагается выполнить набор инструкций (установлена галка " As expressions", то в каком формате нужно писать этот набор? Это кусок Си кода или еще как? В хелпе не нашел. Попробовал что-то типа " X = 1; " - вроде работает... Далее, при каких таких условиях потребовалось бы выполнить некую утилиту по достижении точки останова? Если кто пользовал, можно ли пример? И наконец, жаль, но вроде как "продолжить программу через несколько сек." - это именно притормозить программу на это время. Я сначала обрадовался, что нашел аналог LiveWatch из IAR, но в Иаре сделано так, что прога не останавливается - просто каждую секунду запрашиваются текущие значения переменных из окна LiveWatch.
2. Можно сделать точку останова типа watchpoint на переменную из ram. По факту чтения или записи возможны все действия, что и в п.1. Это в том числе и то, что предлагает и J-Link'овский GDB сервер.

В целом возможности отладки неплохие, тем более что судя по хелпу из Эклипса эти CDT tools активно развиваются и уже сейчас можно слегка расширить эти возможности установкой доп плагинов.
Знакомясь с Эклипсой, я скомпилировал тестовый проект в нем как через Yagarto/GCC так и через IAR plugin. Думаю, на текущий момент это наиболее оптимальное сочетание средств: с одной стороны используются шикарные возможности редактора Эклипса, с другой есть гибкость в оперативной смене компиляторов GCC / ICC. Не знаю как дальше это пойдет, т. к. Juno загружается на моем весьма недревнем ноуте раза в 3 дольше Indigo...
Только тяжелый вопрос с изучением make файлов как всегда остался пока неразрешенным... )))

Только так и отлаживаюсь и все работает. А какой смысл сначала отлаживать другой код, а потом еще отлавливать ошибки, которые вылезут при включении оптимизатора (забытые volatile, гонки и т.д)? Да, есть тонкости - отлаживаться надо с включенным окном дизассемблера, потому что не каждому С-выражению соответствует какой-то код. Да, иногда нельзя поставить точку останова, если этот участок исходника был соптимизирован. Но можно найти нужное место и вставить точку останова в окне дизассемблера.

Что может не работать?
Работало, может не всегда сразу так как хотелось бы, но на то она и отладка, чтобы ошибки устранить. Зашивать-то всё равно Release надо.

И еще у меня часто бывало невозможно посмотреть значения переменных - печатались какие-то левые значения. Это было в Иаре. Вот тогда я и решил, что дебаг - все же для отладки, а релиз как бы должен гарантированно собираться без ошибок. Конечно, логично зашивать в МК то, что отлажено. Надо будет потестировать GDB и IAR плагин в этом смысле...
Начал с Иаровского плагина. На моем тестовом проекте ПОКА нормально дебажится релиз...