[MKdemiurg 1]

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

Появилась необходимость удалённой отладки устройства. Для чего хотелось бы сохранить Call Stack в энергонезависимую память по запросу ( HardFault, WD, внешний запрос)

Не очень понятно как правильно развернуть стэк в bare metal...

На сколько я понимаю это нетривиальная задача . Может есть готовые решения под С и GCC?

[jcxz 184]

1 минуту назад, MKdemiurg сказал:

На сколько я понимаю это нетривиальная задача . Может есть готовые решения под С и GCC?

Что именно в ней "нетривиального"? Стек - это просто область памяти. Берёте и сохраняете.

[Arlleex 131]

А какой толк от полученной каши в виде каких-то там дампов памяти? В МК понятно, взял и сохранил сколько нужно.

Вот только получить такой же вид, как это делает IDE в момент отладки ПО, не так просто: IDE в отладочной сессии генерит себе кучу вспомогательной информации.

Размотать Call Stack удаленно работающего бинарника без этой инфы занятие такое себе.

В первую очередь надо определиться с тем, как полученные дампы рабочей области стека МК быстро и наглядно расшифровать.

[MKdemiurg 1]

6 minutes ago, jcxz said:

Что именно в ней "нетривиального"? Стек - это просто область памяти. Берёте и сохраняете.

ну это понятно. Мне надо его раскрутить потому что сохранять 4кБ такое себе...

2 minutes ago, Arlleex said:

Размотать Call Stack удаленно работающего бинарника без этой инфы занятие такое себе.

Ну по большому счету мне нужно получить только Call Tree, чтобы c .map уже пройтись  и выяснить поведение устройства перед HF

4 minutes ago, Arlleex said:

В первую очередь надо определиться с тем, как полученные дампы рабочей области стека МК быстро и наглядно расшифровать.

Да, это наверно правильно заданный вопрос.

[jcxz 184]

6 минут назад, MKdemiurg сказал:

Ну по большому счету мне нужно получить только Call Tree, чтобы c .map уже пройтись  и выяснить поведение устройства перед HF

Если вы хотите получить тот же вид, что в отладчике, то очевидно и нужно делать то, что делает отладчик: Используя сохранённый дамп и отладочный elf-образ, сделать визуализацию на их основе.

PS: Эпическая задача. Если совсем уж нечем на работе заниматься.... 

...и для "выяснения поведения перед HF" это конечно делать не нужно.

[Arlleex 131]

15 минут назад, jcxz сказал:

PS: Эпическая задача. Если совсем уж нечем на работе заниматься.... 

На самом деле вполне интересная, если подойти творчески и сделать нечто бОльшее, чем текстовая плевалка в какую-нибудь черную консоль
 

Цитата

Используя сохранённый дамп и отладочный elf-образ, сделать визуализацию на их основе.

Отладчику проще: ему не нужен полный дамп, он в каждом сохраненном frame stack-е знает положение указателя PC и LR, поэтому может проходиться "по верхушкам", не имея всего дампа.
 

15 минут назад, jcxz сказал:

...и для "выяснения поведения перед HF" это конечно делать не нужно.

Соглашусь

[haker_fox 60]

7 minutes ago, Arlleex said:

На самом деле вполне интересная

Кстати, да! Но я ограничился обработчиком HF, который выводит содержимое регистров и расшифровку их битов по мотивам документации с arm.com. Также вывожу по 32 слова MSP/PSP, которые, к слову, за несколько лет ни разу не пригодились мне. Но, ИМХО, вся эта информация полезна под отладчиком. Когда прибор работает уже на подстанции в шкафу и вылетает HF - это печально. Хотя однажды такое было, и всё же помогло по содержимому PC установить причину. Не сразу, конечно: вот она - проблема! Нет, потребовалось несколько дней с анализом других данных, пржде, чем проблема была обнаружена и устранена.

 

@MKdemiurg, а какая архитектура ядра? На Cortex-M3 и выше HF довольно информативен. А вот на Cortex-M0 - это игра на сообразительность: там данных очень мало. Нужно действительно думать и усиленно думать🤣💗

[jcxz 184]

1 минуту назад, Arlleex сказал:

Отладчику проще: ему не нужен полный дамп, он в каждом сохраненном frame stack-е знает положение указателя PC и LR, поэтому может проходиться "по верхушкам", не имея всего дампа.

Так сохранятель в прошивке - тоже знает их положение. Единственное, чего у него нет: elf-образа. Чтобы разрисовать красиво. Но если ТС будет при каждой перепрошивке устройства сохранять в свою энергонезависимую память и elf - то у него будут все возможности отладчика.

PS: Другое дело, что это - нафик не нужный сизифов труд. Многие годы уже сохраняю в энергонезависимую память стеки критических ошибок. В разных проектах. И ни разу мне не приходило в голову эмулировать "Call stack" отладчика.  

У меня уже лет 15 примерно так выглядит дамп ловушки критической ошибки:

И мне его хватает для "раскрутки".

[MKdemiurg 1]

13 minutes ago, haker_fox said:

 

 

@MKdemiurg, а какая архитектура ядра? На Cortex-M3 и выше HF довольно информативен. А вот на Cortex-M0 - это игра на сообразительность: там данных очень мало. Нужно действительно думать и усиленно думать🤣💗

M4

[MKdemiurg 1]

24 minutes ago, jcxz said:

Так сохранятель в прошивке - тоже знает их положение. Единственное, чего у него нет: elf-образа. Чтобы разрисовать красиво. Но если ТС будет при каждой перепрошивке устройства сохранять в свою энергонезависимую память и elf - то у него будут все возможности отладчика.

PS: Другое дело, что это - нафик не нужный сизифов труд. Многие годы уже сохраняю в энергонезависимую память стеки критических ошибок. В разных проектах. И ни разу мне не приходило в голову эмулировать "Call stack" отладчика.  

У меня уже лет 15 примерно так выглядит дамп ловушки критической ошибки:

И мне его хватает для "раскрутки".

Мне нужен backtrace.

И что вы потом делаете с дампом стека? вручную его раскручиваете?

[jcxz 184]

15 минут назад, MKdemiurg сказал:

И что вы потом делаете с дампом стека? вручную его раскручиваете?

Открываю дамп + открываю листинг и...... глазами и головой. Там вроде всё проще некуда.

15 минут назад, MKdemiurg сказал:

Мне нужен backtrace.

Для этого вам нужно либо трэйсер покупать и подключать; либо - МК с ETB. Никакой Call Stack не поможет в backtrace-е. В общем случае...

[Arlleex 131]

1 час назад, haker_fox сказал:

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

Мне и ловушки-трейсеры стека (и дампа регистров) пригождались, разве что, пару раз за всю практику...

[Stepanov 8]

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

Было время когда пару раз приходилось через светодиодик отлаживать, пачка импульсов с TRACE(...); на осциллограф и бумажка с карандашиком.)

[MKdemiurg 1]

После танцев с бубном и поиска нашёл то, что было нужно.

А именно бэктрейс по стеку для армов от друзей из Солнечного Бейджина.

https://github.com/armink/CmBacktrace

Оно даже работает и можно просто по листингу пробежаться до инструкции вызывающей ХФ.

Конечно, при условии что стэк целый.

И это проще чем переделывать  _Unwind_Backtrace.