При работе симулятора в Студии в окне Watch значение некотрых переменных отображается и модифицируется в ручном режиме нормально. Но о некоторых из них отладчик пишет

Not in scope
или
Location not valid

В справочнике про эти сообщения ничего не нашел. Ну, если с первым еще более-менее ясно (ясен смысл, хотя когда именно переменная попадает в видимость - не всегда совпадает с моими представлениями), то вот второе сообщение меня сбивает с толку. Во-первых, на это сообщение, по-моему, попадают чаще всего (но не всегда!) enumerated переменные, элементы структур. Но иногда и обычные (я просто изменял тип переменной из ENUM в CHAR - для пробы).

Можете объяснить толком точный смысл этих сообщений - или послать туда, где объясняют?

И еще. Влияет ли на видимость переменных многофайловость проекта?

Спасибо!

А, собственно, что тут непонятного?

1) Многофайловый проект или нет - не имеет значения.
2) Имеет значение - видима ли переменная в момент отладки.
3) Location not valid - скорее всего - переменная была выкинута оптимизатором.

Особенно это очевидно при работе с локальными переменнами.
Например в какой-то ф-ции есть локальная переменная. Компилятор её разместил в регистре. Так как её вам показать до того пока она внесена в регистр и после освобождения?

Спасибо за ответ!

Непонятно как раз, что делать-то? И, судя по форуму на ФРИКах, эта непонятка не только у меня. Их достойных ответов упомяну, пожалуй, этот и последний постинг уважаемого шведа от Jul 17, 2010 - 02:01 PM здесь. Для тех, кто не дружит с аглицким, ответ от SasaVitebsk дополню следующим почерпнутым только что знанием:

Что можно сделать?

1) Ждать нового релиза ВинАВР и-или Студии
2) Выключить оптимизацию (но программа получается, вообще говоря, уже далеко не та)
3) Внимательно просматривать в режиме дизассемблера и увидеть, в каких регистрах возникает кратковременно именно то значение, для хранения которого Вы создали переменную (а сука оптимизатор выкинул).

Больше я ничего не понял. Или есть еще трюки?

Отладка оптимизированного кода - это вообще один большой трюк Так что п2 (Выключить оптимизацию) это то, что надо сделать в первую очередь, если хотите отлаживаться.
Отладка с включенной оптимизацией имеет смысл только тогда, когда программа в отладочном режиме работает, а в релизе - нет (да и то сразу бросаться ее отлаживать в дебагере не стоит - сначала стоит посмотреть что вы могли написать неправильно. В 90% случаев это будет опущенный volatile или не инициализированные переменные)

4. Как вариант можно для отладки алгоритма к такой переменной добавить static volatile, тогда компилятор её не соптимизирует в регистр.

Вы знаете, может быть и так. Я попробовал чуть иначе. Объявил переменные, за которыми хочу следить, за границами функции (в данном случае - main()). И оптимизатор их не съел Вижу в окошке Watch, слава Богу.

Единственное, что сама Студия не позволила мне сделать для полного ЩАСТЯ, это сохранить ENUM переменные. Т.е., вынес за фунцию - появились в Watch окне (точнее, окно перестало ругаться). И даже пишет мне в качестве значений именно те символьные имена, которые я заложил в перечисление ENUM. Но! Не принимает Студия такие переменные в качестве точек остановки по данным. Пишет, что для использования обращения к данной переменной в качестве условия бряка необходимо, чтобы пременная была целой или флоат. Увы! Но это уже терпимо. Я даже поставил условную компиляцию так, что для эмуляции переменные глобальны и char, а для железки - локальные и enum. Хотя здесь уже просто можно было бы вместо enum поставить несколько дефайнов:

Было:


Можно:


типа так...

Вы творите одну глупость за другой. В смысле я не хочу вас обидеть. Просто вы пока не понимаете что творите.

1. Перенеся переменные вы по сути написали совершенно новую программу, которая никакого отношения к предыдущей не имела. В результате после возвращения переменных в состояние локальных - можете получить неработоспособную программу (ввиду непонимания выделения памяти под переменные)
2. Чтобы вам яснее было - если компилятор выкинул данную переменную - значит так и надо! И у вас это не должно вызывать никаких эмоций. Он не выкинет то, что необходимо при правильно написанной программе.
3. При отладке - локальные переменные обычно видны. Просто сразу указано расположение - регистр или 2 регистра. Для AVR регистры можно посмотреть и непосредственно в окне регистров. Проблем, обычно не возникает.
4. Я обычно отлаживаю непосредственно по оптимизированному коду. Иногда возникают неудобства связанные с груповой оптимизацией - то есть когда сразу ч/з несколько операторов перескакивает, но обычно это тоже не вызывает неприятностей. Всётаки отлаживать надо на более высоком уровне, чем оператор. Обычно я только детали контролирую, а программу лучше внимательно просмотреть. Если видите, что какие-то проблемы.
5. Иногда (крайне редко) возникает потребность просмотреть что-то что соптимизировал компилятор. Честно говоря, в 95% случаев у меня это просмотреть правильность занесения константных выражений, при сложных взаимозависимостях. Либо какие то адресные операции. Конечно, это можно сделать и по листингу, включив соответствующие опции, но ... лень, как обычно. Проще вырубить оптимизацию - посмотреть и опять врубить. Иногда требуется более внимательно просмотреть исполнение того либо другого куска кода, который был серьёзно соптимизирован - тогда я вызываю ассемблер - и вперёд на танки.
Это всё - крайние случаи. Если они возникают у вас часто, то что-то не так в датском королевстве.

Писать и отлаживать всё таки надо именно в Си. Дополнительным аргументом для этого станет такой момент: при переходе на ARM там отладка по ассемблеру вообще очень тяжела. Даже с константами и то беда. Переходы и прочее... Есть моменты, которые вобще отладчиком не посмотришь (из за конвеера). И как быть тогда?

Надо поднимать уровень отладки выше. А писать более вдумчиво.

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



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


улыбнуло...

Сталкивался с похожей ситуацией. Страдает не только студио, но и иар. Случайно такое вот решение:
Было
for(;;)
{
// Тут собственно вся программа внутренние переменные не видны
}

Сделал:
while(1)
{
// А тут всё видно и работает
}

P.S. Логичного объяснения не нашёл. Но всё больше на ассемблере теперь работаю.

Просто Вы пока не понимаете, что я понимаю, а чего не понимаю

Посмотрим вместе.

ну почему же так категорично? Да, могут быть случаи, что ошибка проявится именно в том варианте программы, который я не вижу в отладчике, ибо перенес переменные в глобальные. Может. Но далеко не всегда. И "совершенно новой" моя программа не стала. Я просто смог в симуляторе отследить поведение проги в том switch, который управляется перенесенной переменной PrPhase. Иначе говоря, мне нужно гарантированно добраться до того или иного case, вот я и захотел видеть управляющую переменную. А предметом отладки были, например, численные значения арифметических выражений или еще какая-то фигня. И, Вы знаете, очень даже удобно оказалось видеть PrPhase.

Иными словами, меня совсем не возмущает то, что

Я просто хочу в нужном мне случае этим процессом управлять. Вот, нашел. И очень доволен.

Ведь и Вы это делаете. Вы пишете

Вот видите, Вам можно, а другим нельзя?


Я, кстати, пишу и отлаживаю именно на Си, хотя, ИМХО, здесь нечем гордиться. Просто мне это удобно, а товарищам, которые пишут на АСМе, я ничего не советую, они же взрослые пацаны. Я это к чему - когда я обращаюсь по конкретному вопросу, то и ответы хочу видеть конкретные, а не общие рекомендации по выбору языка программирования. Без обид, дружище!

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