Интересно - есть-ли у IAR возможность вставки префикса в начало каждой функции при компиляции?
Т.е. - чтобы после входа в каждую функцию в проекте, после PUSH, он вставлял некий фиксированный код (hook). Возможно это несколько ассемблерных строк или просто вызов функции BL (естественно с предварительным сохранением исходного LR на стеке). Видел такую возможность у какого-то компилятора, не помню точно, но вроде у CCS.
Думаю добавить в проект функционал контроля стеков задач. И думаю как это удобнее всего сделать. С помощью такого хука это можно было-бы реализовать.

В яре такого вроде не было, лично я так и не нашел. Такое точно есть в гцц. Совсем недавно натыкался на бложик с описанием такого механизма. Там его применяли для построения стека вызовов

А в idle задаче не хотите делать такую проверку?

Во-первых: в idle-задаче у меня выполняется WFE.
Во-вторых (и главное): в idle-задаче управление находится когда все задачи находятся в ожидании семафора, майлбокса, ... или просто выполняя sleep(N-секунд). Т.е. - когда ничем не заняты. А наибольшее использование стека происходит как раз когда задача что-то делает.

Да, вроде, ни первое ни второе не помеха хорошему танцору. Забейте стек шаблоном и проверяйте его. А как закончите проверку, сразу в спячку.

Забитие шаблоном - не лучший метод. Так как стек успеет переполниться, ПО повиснет, а я об этом так и не узнаю. Не говоря уже о ненулевой вероятности совпадения записываемых данных с шаблоном.
Был бы в Cortex-M более функциональный MPU, сделал бы на нём.
А так: или префикс в начало каждой функции или периодическая проверка в ISR высокочастотного таймера. Других способов не вижу пока.

В ассемблерном листинге заменить все BL на запрещённый опкод (уж это, наверное, можно автоматизировать). Далее обрабатывать исключение на invalid opcode.

J-Link Pro в IAR показывает полную пирамиду вызовы в реальном времени в окне timeline.
И весь перечень вызовов в любой точке останова в окне Call Stack.
Если применить MQX то будет отображаться стек вызовов для каждой задачи отдельно.
Также будет виден максимальный расход стека для каждой задачи.
Также покажет автоматически все повреждения служебных структур RTOS.
Покажет и переполнение менеджера памяти и фрагментацию памяти.

И что это даст? Мне нужно максимальное использование стека. По всем задачам.


У меня не MQX. И как интересно MQX это вычисляет? Периодически анализируя затёртость шаблона в отдельной сервисной задаче? Плохо, так как это никак не спасает при переполнении стека.
Я прекрасно понимаю, что заполняя стек шаблоном, можно с большой долей вероятности оценить глубину использования стека. И собственно так сейчас и делаю. Но это работает, только если нет случаев переполнения стека!


Ну да. А ещё BLX. А ещё и все B проанализировать, так как они тоже могут являться вызовами функций (если такой вызов находится в конце другой функции).
Да и что потом с этим листингом делать? Как из него прошивку получить?
Заменять тогда уж надо не BL, а все PUSH и SUB SP,#...

да простят меня ....
переобразовать return в Return по тексту проекта или тамгденадо


С аргументом для ret надо вывернуться и для void f() всеравно писать return.

Да. Это опция компилятора/линкера -pg
Можно почитать про mcount и profile hook.
Наверняка какой то профайлер и для яра имеется.

Ну да:
void func1() { func2(); }
void func2() { func3(); }
void func3() { func4(); }
...
А теперь представьте, что переполнение стека произошло ещё в func1(). До func4() (где Вашим способом это можно будет обнаружить) дело уже может и не дойти, так как к этому времени перепахает полпамяти.
Да и очень желательно всё-же оставаться в синтаксисе языка си, который не обязывает ставить return в таких функциях.
К тому же: не все функции, которые будут в результирующем коде, присутствуют в исходниках (оптимизатор тоже может сам генерить функции).
Я уже не говорю, что "вывернуться с аргументом для ret" получится далеко не для всех аргументов.
И вообще - надо чтобы си-исходник оставался обычным читаемым си-исходником, а не некоей тарабарщиной на непонятном языке.

PS: Вобщем, похоже, что вариант с высокочастотным таймером - безальтернативен для IAR...


Вот потому и спрашиваю. Прошерстил мануал IAR-а - не нашёл подходящего. Может плохо искал.....

Вот и повод перейти на gcc)))
Я уже давным давно на gcc подсел - ни разу не пожалел.

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

А идея про вставку хуков довольно наивна. В либы все равно хуки не вставить.
Да и будет повод для появления ошибок Гейзенберга.

Сделаю вид, что не заметил вашего комментария.

Терпимо: у меня в проектах нигде нет либ. Всё только в исходниках.


Это кто такой? Я его знаю?
Ну тогда и не будем его брать в команду раз он ошибки делает

Т.е. ни printf, ни sprintf, ни какой-нить там strcpy или memcpy ?



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



Гейзенбаг

Не поверите, но sprintf() не использую нигде в embedded (в IAR и CCS по-крайней мере). В IAR-проектах вместо неё использую _Printf() - она удобнее.
И вызываю её чаще всего с переключением на отдельный стек (только ейный) защищённый семафором. Так как sprintf()-подобные функции отъедают много стека, а у меня в большинстве проектов памяти мало - приходится экономить и сериализировать выполнение _Printf().
Хотя согласен - завтра может понадобится и её напрямую вызывать из задач без переключения стека. Но с _Printf() чуть проще - ей в качестве методов вывода передаются указатели на мои собственные функции (putchar()-подобные), которые должны вызываться, я думаю, на самой глубине использования стека. Если между входом в _Printf() и входом в мой метод putchar() стек не успеет переполнится, то уже внутри моего putchar() SP зафиксируется.
memcpy() конечно использую, но у неё не очень большая глубина использования стека - массивов на стеке она по-крайней мере не выделяет.

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

Вроде бы всю жизнь это называлось "пролог".

По этому слову в доке IAR тоже ничего не находится....

Специально залез в доку IAR посмотреть наличие проблемы, потому как немыслимо чтобы IAR не выделял внимания контролю стека.
Ну и точно, там море возможностей прецизионно контролировать стек.
Читайте EWARM_DevelopmentGuide.ENU.pdf со страницы 92



Почему же, верю.
В моих проектах можно найти по 3-4 отдельных автономных реализаций sprintf.
Ибо каждая RTOS, каждый пакет претендующий на мультиплатформенность содержит файлы с переписанными стандартными библиотеками C-и.
Это не удобство, а трагедия, поскольку возникает еще один повод для путаницы.

Именно эту доку я и изучал. На этой странице у меня "CHOOSING A LINKER CONFIGURATION FILE" и др. мало относящиеся к контролю стека главы.
Не сочтите за труд указать название главы?


Я не гонюсь за мультиплатформенностью. Она малополезна в embedded, когда проект привязан даже не только к ядру, но и более сильно - периферии.

"Stack usage analysis"

А кто гонится? Все мы работаем одинаково.
Поэтому я и знаю где реальная проблема обсуждается, а где надуманная или несущественная.

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

Не подходит. Толку от него мало. В коде куча косвенных вызовов функций.
И это не подходит: but if there are indirect calls (calls using function pointers) in your application, you must supply a list of possible functions that can be called from each calling function.
Так как не я один пишу этот код, а есть товарищи, любящие всякие классы с виртуальными член-функциями и пихающие их куда нужно и не нужно. А заставить их делать это для своего кода - нереально. Да и малоэффективно.
Да и опять-же - в случае использования чужого кода (всяких стеков и либ), что делать? Шерстить весь этот код для supply a list of possible functions???
Нужен именно run-time контроль, а не build-time.

Не куча, а где нибудь в районе сотни.
IAR все косвенные вызовы аккуратно показывает в Call graph-е.

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

Про эффективность не понял. Анализатор вызовов абсолютно точно считает стек.
И если стоит задача урезать максимально стек лучшего способа не существует.

Это Вы так считаете. И я. А товарищам объяснить невозможно - они всё равно делают как делали и не хотят ни в чём разбираться. А ПО потом глючить начинает совсем в другом месте, не там где набыдлокодили.


Неэффективно, так как требует постоянного контроля кода, заполнения чего-то там при каждом изменении/добавлении/убирании этих самых функций. Да и ещё и правильного заполнения. 100% что забудут добавить или неправильно добавят или.... и всё насмарку - опять ищи почему глючит.
Механизм контроля должен быть внешний, не требующий постояных трудозатрат на его поддержание и чтобы его один раз реализовал и забыл. И только включать быстро (одним дефайном или ещё чем) когда надо и отключать когда не надо.
А иначе проще тогда уж по-старинке: залить стеки шаблоном и глазами проконтролировать затёртость шаблона.

Т.е. хотите забабахать статистический движок как в линуксах?
И стека не жалко, и ресурсов процессорного времени и риалтайма?

Я думаю если даже Segger этого не сделал, то это никому и не надо.
Старых добрых методов хватает.

Да и статистика дело тонкое.
Не скажете же заказчику после того как все рухнуло, что вероятность переполнения стека была всего то 0.1% с уровнем доверия 95% при эмпирической гипотезе о распределении.

Причём тут какой-то движок? Причём тут заказчик??? Речь идёт об отладке ПО и средствах отладки.
Идея простейшая: при каждом изменении SP (в си - после входа в функцию и выделения стекового фрейма), проверять SP на допустимость (нахождение в некотором диапазоне адресов). Переменные, хранящие контролируемый диапазон, обновлять при каждом переключении задач (в соответствующем хуке ОС).
Это если бы была возможность написать свой пролог функции.
Если нет, другой способ: так же контролировать SP на нахождение в диапазоне только периодически, как можно чаще, в высокочастотном таймерном прерывании.

Дополнительного стека для этого не нужно. Процессорное время конечно нужно, но этот контроль нужно включать только тогда когда нужно - при отладке, при возникновении подозрения на переполнение стека, при каком-то непонятном поведении ПО, чтобы отбросить вариант переполнения стека.
Когда проверять не нужно - просто комментируем соответствующий #define и всё. У меня сейчас так же уже реализована проверка на максимальную длительность запрета прерываний в ПО: запускается ВЧ прерывание и контролируются интервалы времени между прерываниями. Работает отлично - уже не одно место нашёл, где коллеги кривыми ручками надолго запрещали прерывания, нарушая тем самым работу драйверов периферии.
Можно конечно по-старинке: просматривать затёртость шаблона заполнения стека. Но это менее удобно и самое главное - высока вероятность пропуска некоторых случаев переполнения стека.

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

Этот пункт вроде проехали. Это делать нет смысла. Статический анализатор по сравнению с этим гораздо легче настроить.
Если, конечно, не брать в расчет неких демонов-товарищей, целенаправленно мешающих настроить анализатор.



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

А про контроль времени выполнения прерываний и их блокировки я уже говорил.
J-Link с точностью до такта логирует все! без исключения события прерываний и ведет их статистику (мин. макс. интервалы, длительности и проч. )
Здесь ничего "реализовывать" не требуется.

Что такое "Статический анализатор" и как его настроить?


Вопрос не про линух.


Как этим пользоваться? А если длинный запрет прерывания происходит только иногда, достаточно редко, при совпадении неких условий? Просматривать полотенца логов и искать?

Ну здрассте. Есть же watchpoint, он же data breakpoint.

А каким образом с его помощью можно контролировать SP или доступ к памяти через SP?
Оно вроде насколько я знаю только контролирует доступ к памяти вне зависимости от регистра из которого была запись/чтение. Или у меня J-Link какой-то урезанный???

Моё дело - предложить, ваше дело - отказаться. Я вижу техническую возможность.
Можете упираться и критиковать - мне всё равно

Да никак, никому это не нужно.

Сначала скажите, вы боретесь с ошибкой или с саботажем?
Если с ошибкой, то ставите watchpoint на проблемном месте и находите баг за считанные минуты. Тут даже говорит не о чем.
Подбирать нужную глубину стека новички учатся на первый год стажировки.

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

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

Скажем засекаем метки времени в своем прерывании и делаем останов когда время затянулось дольше обычного.
Правда без таймлайна JLink тут тоже мало толку будет.
Таймлайн это все!

Я вижу саботаж только здесь.
Вы действительно не понимаете сути вопроса или это троллинг?
Мне кажется вопрос кристалльно ясен. Ситуация:
void f()
{
char b[100];
b[0] = некое_выражение;
...
}
Эта функция вызывается когда до границы стека текущей задачи осталось например 50 байт.
Внимание вопросы:
Что будет со стеком и с SP?
Что будет с памятью, находящейся ниже стека текущей задачи?
Каким образом при помощи watchpoint (или каких-то других сервисов) обнаружить факт выхода SP за границы стека текущей задачи (и записи по SP) в такой ситуации?
При условии что в памяти расположенной ниже стека текущей задачи, могут находиться другие переменные, запись в которые через другие регистры (не SP) - штатна, и запись через SP из других задач - штатна, и не должна вызывать срабатывания механизма обнаружения переполнения стека.
В качестве доп. условий: работа идёт в многозадачной среде, есть N задач, каждая со своим стеком.


Если частота его будет такова, что прерывания будут происходить каждые десяток-два команд, то высока вероятность того, что SP уже сбился и выполнение начало куда-то уходить, но содержимое регистров/памяти ещё не успело разрушиться настолько что невозможно найти место где произошло выполнение или CPU вообще не завис.
Т.е. - функция то исправна, и она продолжает выполняться, ну разрушила она чужую память, находящуюся ниже её стека, ну были там адреса возврата, по которым PC улетит в неизвестном направлении, но это случится только когда ОС передаст управление той задаче, чьи данные были разрушены. Это может быть не скоро и до этого успеет сработать ловушка по ВЧ прерыванию, контролирующая SP.

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


Это Вы про то что я писал про контроль длительности запретов прерываний? Ну так у меня это примерно так и работает, только не надо ставить такие метки в каждое прерывание, убирать их и пр. гемор. Просто разрешается некий #define, начинает работать ВЧ прерывание, выполняющееся на высшем приоритете, и оно измеряет временные интервалы между своими вызовами и если есть преывешние - ахтунг! - попадаем в ловушку.
В любой момент когда возникло подозрение можно этто define включить и проверить. Это просто. Хочется чтобы и контроль стека включался так же просто.

У меня было впечатление, что вы человек достаточно опытный в этих делах. Если не можете сами ответить на эти вопросы - что ж, у меня было неверное впечатление, должно быть.

Коллеги, давайте жить дружно!
Хочется помочь - помогите, нет желания - промолчите.

Ситуация совершенно не реалистичная.
Разработчик под RTOS никогда так не сделает. И вы наверняка так не делаете, ибо эти грабли быстро все понимают.
Здесь либо используется динамическое выделение, либо массив делается глобальным, либо разработчик сразу же тестирует этот код на переполнение стека.

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




А это делается в несколько ходов.
Сначала вставляется лог приема-передачи пакетов.
Потом по логу обнаруживается несоответствие поведения.
Находится машина состояний ответственная за соответствующее поведение.
Потом вставляются в ветви состояний команды типа ITM_EVENT(можно даже с аргументом в виде значение стека) и вставляется код с остановом с идентификацией аномального поведения.
И в таймлайне после останова уже смотрят какие прерываний были, сколько длились и какие состояния автомата предшествовали.
Если как в вашем случае обнаруживаем искаженные данные, то ставим на них watchpoint. И все!
На следующем прогоне видим кто (какая задача, процедура, функция ..) портит данные.

По такому алгоритму обнаруживаются все конфликты памяти, а не только возникшие из-за стека.

У меня ошибок стека уж не помню сколько лет не было.

Ну Вы прямо, как в анекдоте с объявлением на столбе - "Могу обучать игре на баяне, английскому языку, использованию watchpoint, но не хочу".


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

Могу рассказать анекдот про вас, но не хочу

Вообще-то это Ваш совет был использовать watchpoint-ы для обнаружения случаев переполнения.
Я знаю что такое watchpoint, но не приложу ума как его можно использовать в такой задаче.
Если Вы реально хотите посоветовать, так посоветуйте. Если просто хотели показать какой умный - лучше пройдите мимо.

Разве не очевидно?
Настраивать watchpoint на область памяти некоторого разумного размера за стеком, куда полезут данные при переполнении. Настраивать в переключалке задач, чтобы контролировать актуальный стек. Стеки разместить с нужным выравниванием, чтобы всё это было возможным.
Я не пойму, это какие-то непостижимые секреты мироздания?

Не понимаю... В чём её нереалистичность??? Под RTOS нельзя объявлять массивы на стеке?


Попробуйте иногда заглядывать в результирующий асм-код после компилятора.
При выделении стекового фрейма на входе функцию, компилятор удаляет этот фрейм только при выходе из функции. По-крайней мере и IAR и CCS так генерят.
И такой супервизор может пропустить это только если выход случится быстро после входа, что маловероятно (хотя вполне возможно - такой способ не даёт 100%-гарантии обнаружения).


Очень сложно и громоздко.
Представьте что этот сбой происходил не каждый раз при тестировании, а только иногда редко, выявлялся установкой на прогон нескольких устройств и их кргулосуточной работой.
Просто он проявлялся при попадании определённых запросов от клиента в определённые времена работы ПО, что происходило редко и недетерминированно по времени.
Это придётся кучу логов перелопатить и watchpoint-ы не помогут - много устройств - неужто на каждый комп с JTAG-ом ставить?


char b[100] - это только для примера. Если там будет char b[10] - легче что-ли?
Или например - просто вызов sprintf()


Какой для этого J-Link нужен? Мой J-Link не умеет "Настраивать watchpoint на область памяти", а только на конкретный адрес. Ну можно конечно выровнять стек на границу степени 2 и настроить на адреса ниже воспользовавшись маской адреса. Но это тогда куча ОЗУ на это понадобится дополнительного.
А её просто нет. У нас проект уже большой, там ОЗУ не хватит уже даже на массив из нескольких десятков байт, не то что выровнять все стеки всех задач (их около 10) да ещё выделить ниже каждого по приличному куску памяти.
Если-б у меня было столько памяти, я бы просто задействовал MPU: при входе в задачу стек в отдельный регион с разрешением для него, для BSS - другой регион с защитой и т.п. И все регионы на расстоянии друг от друга. Я об этом писал ещё в самом начале топика.
И во-2-ых - события переполнения могут происходить редко и приходится ставить несколько устройств на длительный прогон. И нет возможности сидеть над каждым устройством с JTAG-ом.

О господи. Эти самые watchpoint можно настраивать через регистры без всяких жтагов.

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

Хорошо. Но как быть с ОЗУ?


Не вижу моря. Вам видно виднее сколько памяти в моём проекте.

Ваш проект не при чем.
Просто вы не привели никакой альтернативы статическому анализу стека да еще при дефиците памяти.

Я так и дождался от Вас расшифровки термина "статический анализатор стека", может поэтому и не привёл. Не знаю что это такое.

Ну вы же не расшифровываете что такое у вас MPU и почему для работы с ним нужно много памяти.
Включайте телепатию.

Если бы Вы когда-нибудь разрабатывали ПО для МК на ядрах Cortex-M3/4, то знали бы что такое MPU.