Обязательный префикс функции. Опции

[jcxz]

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

[ig_z]

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

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

[ViKo]

Думаю добавить в проект функционал контроля стеков задач. И думаю как это удобнее всего сделать. С помощью такого хука это можно было-бы реализовать.

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

[jcxz]

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

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

[ViKo]

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

[jcxz]

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

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

[scifi]

Других способов не вижу пока.

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

[AlexandrY]

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

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

[jcxz]

J-Link Pro в IAR показывает полную пирамиду вызовы в реальном времени в окне timeline.
И весь перечень вызовов в любой точке останова в окне Call Stack.

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

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

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

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

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

[k155la3]

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

Код

#define RET_SWITCH

#ifndef RET_SWITCH
#define Return return
#else
#define Return SavePC(); SaveStack; \
                       return(1); \
#endif

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

Сообщение отредактировал k155la3 - Aug 3 2016, 13:18

[demiurg_spb]

Такое точно есть в гцц.

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

[jcxz]

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

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

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

Наверняка какой то профайлер и для яра имеется.

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

[demiurg_spb]

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

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

[AlexandrY]

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

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

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

[demiurg_spb]

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

[jcxz]

А идея про вставку хуков довольно наивна. В либы все равно хуки не вставить.

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

Да и будет повод для появления ошибок Гейзенберга.

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

[AlexandrY]

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

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

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

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

Это кто такой? Я его знаю?

Гейзенбаг

[jcxz]

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

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

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

[scifi]

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

[jcxz]

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

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

[AlexandrY]

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

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

Не поверите, но sprintf() не использую нигде в embedded (в IAR и CCS по-крайней мере). В IAR-проектах вместо неё использую _Printf() - она удобнее.

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

[jcxz]

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

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

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

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

[AlexandrY]

Не сочтите за труд указать название главы?

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

"Stack usage analysis"

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

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

[jcxz]

"Stack usage analysis"

Не подходит. Толку от него мало. В коде куча косвенных вызовов функций.
И это не подходит: 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.

[AlexandrY]

Не подходит. Толку от него мало. В коде куча косвенных вызовов функций.

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

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

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

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

[jcxz]

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

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

Про эффективность не понял.

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

[AlexandrY]

Неэффективно, так как требует постоянного контроля кода, заполнения чего-то там ...

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

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

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

[jcxz]

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

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

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

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

[AlexandrY]

Идея простейшая: при каждом изменении SP (в си - после входа в функцию и выделения стекового фрейма), проверять SP на допустимость

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

другой способ: так же контролировать SP на нахождение в диапазоне только периодически

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

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

[jcxz]

Этот пункт вроде проехали. Это делать нет смысла. Статический анализатор по сравнению с этим гораздо легче настроить.

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

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

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

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

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

[scifi]

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

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

[jcxz]

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

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

[scifi]

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

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

[AlexandrY]

А каким образом с его помощью можно контролировать SP или доступ к памяти через SP?

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

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

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

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

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

[jcxz]

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

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

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

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

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

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

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

[scifi]

Каким образом при помощи watchpoint (или каких-то других сервисов) обнаружить факт выхода SP за границы стека текущей задачи (и записи по SP) в такой ситуации?
При условии что в памяти расположенной ниже стека текущей задачи, могут находиться другие переменные, запись в которые через другие регистры (не SP) - штатна, и запись через SP из других задач - штатна, и не должна вызывать срабатывания механизма обнаружения переполнения стека.
В качестве доп. условий: работа идёт в многозадачной среде, есть N задач, каждая со своим стеком.

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

[demiurg_spb]

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

[AlexandrY]

Мне кажется вопрос кристалльно ясен. Ситуация:
void f()
{
char b[100];
b[0] = некое_выражение;
...
}

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

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

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

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

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

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

[zltigo]

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

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

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

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

[scifi]

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

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

[jcxz]

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

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

[scifi]

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

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

[jcxz]

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

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

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

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

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

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

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

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

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

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

[scifi]

И нет возможности сидеть над каждым устройством с JTAG-ом.

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

[AlexandrY]

А её просто нет. У нас проект уже большой, там ОЗУ не хватит уже даже на массив из нескольких десятков байт, не то что выровнять все стеки всех задач (их около 10) да ещё выделить ниже каждого по приличному куску памяти.

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

[jcxz]

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

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

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

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

[AlexandrY]

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

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

[jcxz]

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

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

[AlexandrY]

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

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

[jcxz]

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

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

[zltigo]

char b[100] - это только для примера. Если там будет char b[10] - легче что-ли?

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

[jcxz]

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

Во-во! А у нас в некоторых задачах по нескольку КБ стеки уже. Не в моих задачах - я стараюсь экономить память. Но я не один участвую в проекте.
Это хорошо как Вы пишете распланировать когда ты сам себе хозяин и только один пишешь ПО.
Но как трудно объяснить людям почему нежелательно использовать sprintf() или что, если например внутри switch в одном case на стеке используется временная структура1, а в другом - временная структура2, по неск. десятков байт каждая, то очень желательно их объединить в union. Ну и т.п.
И что ещё - хорошо, например сейчас определили, что в задаче1 вызывается такая-то функция, которая ест много стека. Хорошо - выделили этой задаче побольше. Но потом, когда уже подзабыли немного, что эта функция много ест при определённых условиях, и сделали её вызов из другой задачи2, имеющей мало стека. И писал эту функцию совсем другой человек. И отладили, проверили - всё ок, работает ок. А ведь эта функция много ест стека только при определённых редких условиях и на этапе отладки эта ветка выполнения кода не случилась, а вылезет оно потом много позже и неожиданно.

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

[scifi]

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

Это ваши проблемы.
Пока я вижу такой настрой: "Вы тут мне предлагайте всякое разное, а я придумаю 1000 и одну причину, почему мне это не подходит".
Хозяин - барин, конечно, но выглядит это всё довольно комично.

[jcxz]

Пока я вижу такой настрой: "Вы тут мне предлагайте всякое разное, а я придумаю 1000 и одну причину, почему мне это не подходит".
Хозяин - барин, конечно, но выглядит это всё довольно комично.

Вообще-то вопрос был конкретный: про вставку пролога в функции в IAR. Ни одного дельного предложения по этому вопросу не было.
И причины я никакие не придумываю: причины все существуют, вот они передо мной, в проектах. Не понимаю - что именно комично? Объём кода большой (около 70 тыс. строк), памяти впритык (почти во всех проектах так), написателей кода - куча, задач - куча. И ПО ведёт себя как-то неадекватно. И что в этом случае делать-то прикажете? При каждой проблеме всё вручную пепрепроверять? Во всех режимах работы и функциях и их комбинациях коих тьма? И делать это после каждого внесения изменений в код каждым разработчиком? И что именно проверять? Как быстро определить где искать проблему???
Для такого тестирования у нас есть полигон, где стоит несколько десятков устройств и работают круглосуточно в реальных режимах работы. И нужно чтобы залить в них ПО и чтобы оно там крутилось долго и когда проявится проблема - вылетело на ловушку, сохранив состояние, по которому можно локализовать проблему.
Вот и хочется для наиболее типичных вариантов проблем (в частности - переполнение стека) сделать какие-то методы быстрой локализации, чтобы в случае поиска проблемы, быстро отсечь эти варианты.

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

[AlexandrY]

И причины я никакие не придумываю: причины все существуют, вот они передо мной, в проектах...

70 тыс. строк это несложный проект. В такой размер помещается простейшая RTOS и с пару десятков модулей с логикой и аппаратной поддержкой.
Такой проект должен делать один человек.
Переполнение стека это не типичная ошибка.
Косвенных вызовов в таком проекте будет не более десятка. У вас все решения лежат на виду.
Проблема чисто организационная. Либо у вас проблема с выбором платформы и отладочных инструментов.

Про "круглосуточно в реальных режимах работы" тоже можете не плакаться.
У нас в Австралийской пустыне и на Тайване техподдержка через teamwiewer собирает логи и апгрейдит программу.
В Саудовской Аравии специалист спокойно сидел на объекте и JTAG-ом ловил баги.
Китайцы, так те самостоятельно отреверсили наши протоколы, присобачили беспроводные модули и сделали круглосуточное наблюдение через облака.

Не далее как вчера мне пришла ссылка на хорошую статью про выбор платформы - http://www.edn.com/electronics-blogs/embed...ampaignId=29190

Сдается мне у вас скверно выбрана платформа ( ну кроме того, что еще и скверная команда)

[jcxz]

70 тыс. строк это несложный проект. В такой размер помещается простейшая RTOS и с пару десятков модулей с логикой и аппаратной поддержкой.
Такой проект должен делать один человек.
Переполнение стека это не типичная ошибка.
Косвенных вызовов в таком проекте будет не более десятка. У вас все решения лежат на виду.

Ну да-да - рассказывайте сколько у меня косвенных вызовов - Вам конечно виднее. И какая разница - сколько их? Что от этого меняется?
И про простейшую ОС - тоже. В каком-то ином мире Вы живёте видно. У нас ОС занимает менее 13тыс. строк. И это с кучей комментов и портом под ядро.
А в 70тыс.строк я ОС не включал. И эти 70тыс. - это почти без комментов.
И про объём это Вы похоже слабо владеете предметом. Вероятно у Вас ПО состоит из набора откуда-то стянутых чужих кусков. И для Вас писать ПО - слепить эти куски воедино. Так и 700тыс. - не проблема.
У нас же в этих 70тыс.строках нет ни строки чужого кода.

У нас в Австралийской пустыне и на Тайване техподдержка через teamwiewer собирает логи и апгрейдит программу.
В Саудовской Аравии специалист спокойно сидел на объекте и JTAG-ом ловил баги.

И что Вы этим хотели сказать??? У нас тоже основное ПО устройства обновляется удалённо через любой доступный канал связи по рабочему протоколу и без всяких тимвьюверов и безопасно. И даже с рестрансляцией через несколько устройств (если целевое устройство не поключено к глобальному каналу связи). И не только основное встроенное ПО можно обновить, но и встроенное ПО любого из входящих в состав устройства связных модулей (ZigBee, RF, GSM, PLC). И тоже безопасно.
Только какое это имеет отношение к вопросу???
Почему не получится отловить JTAG-ом, я тут уже несколько раз объяснил. Если не поняли - извините.

PS: Пустой трёп про китайцев в облаках поскипан.

[AlexandrY]

Только какое это имеет отношение к вопросу???

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

Ну разве это не диагноз?

[jcxz]

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

Я не обсуждаю здесь лошадей, не обсуждаю и проект. Это Вы всё время стараетесь стащить тему во флейм.
Вопрос был конкретный - в заголовке. Или более расширенно - о методах контроля стеков задач в многозадачной среде в общем случае, а не в частных типа: имеем вагон+тележка памяти и можем каждой задаче по мегабайту на стек выделить.
И чтобы это было удобно сделано - при малейшем подозрении на проблему со стеком: включил чекбокс/define, проконтролировал работу девайса в течение длительного времени на нескольких устройствах. И не надо было при каждом подозрении на стек, делать кучу ручной работы (ставить watchpoint-ы, снимать, просматривать стеки задач и т.п.). Я думаю это полезно будет не только в моих проектах.
Недостатки проектов, в которых я участвую, более здесь обсуждать я не намерен. Я их сам прекрасно знаю и чьё-либо мнение здесь на этот счёт меня не интересует.
Если нечем заняться и нечего сказать по существу - лучше пройдите мимо.

[ViKo]

В Кейловской РТОС можно включить контроль переполнения стека, одной галочкой в настройке. Если случится, вылетаем в os_error, и там можно определить, из какой задачи прилетели.

[Kabdim]

Может попробовать использовать MPU? Расставить за концами стеков области с запретом на доступ...
Хотя кмк с такими запросами пора переходить на чип толще, с защитой адресного пространства задач. Ну или программистов строить - устроить кодревью репозитория с прошивкой.

[AlexandrY]

Может попробовать использовать MPU?

Следует перед этим спросить автора, а есть ли у него MPU.
А то оно ведь опционально. И они к тому же разные бывают.

TC похоже этим еще не интересовался даже.
http://www.freertos.org/FreeRTOS-MPU-memor...ction-unit.html

[jcxz]

Может попробовать использовать MPU? Расставить за концами стеков области с запретом на доступ...

Я уже писал про такой вариант. Во-первых: нужно довольно много доп. памяти, а её в обрез; во-вторых: задач около 10 (даже больше), а в MPU регионов всего 8 и большую часть из них я уже использую.

Хотя кмк с такими запросами пора переходить на чип толще, с защитой адресного пространства задач. Ну или программистов строить - устроить кодревью репозитория с прошивкой.

Это точно! Но не получается у меня так, проще уволиться самому...
На следующей работе обязательно для такой задачи буду требовать чип с MMU.

В Кейловской РТОС можно включить контроль переполнения стека, одной галочкой в настройке. Если случится, вылетаем в os_error, и там можно определить, из какой задачи прилетели.

Как это реализовано? Скорей всего - периодический контроль затёртости шаблона в стеке. Именно так сделано в uCOS. Это малоэффективно. Я уже писал почему.

TC похоже этим еще не интересовался даже.

Ну-ну продолжайте острить дальше. Память у Вас видно коротка (а не только в моём проекте), так хотя-бы почитайте весь тред.

[ViKo]

Как это реализовано? Скорей всего - периодический контроль затёртости шаблона в стеке. Именно так сделано в uCOS. Это малоэффективно. Я уже писал почему.

Нет. Там можно другой галкой задавать шаблон (watermark) или не задавать. А проверка все равно работает.

[jcxz]

Нет. Там можно другой галкой задавать шаблон (watermark) или не задавать. А проверка все равно работает.

хм... странно... А как тогда работает? По какому алгоритму. У меня IAR, Keil-а нет.

[scifi]

хм... странно... А как тогда работает? По какому алгоритму. У меня IAR, Keil-а нет.

Мануал намекает, что проверка стека производится во время переключения задачи:

Enabled Stack Checking slightly decreases the kernel performance because on every task switch the kernel needs to execute additional code for stack checking.

[zltigo]

Мануал намекает, что проверка стека производится во время переключения задачи:

Тогда это делается очень просто, но больше для галочки, ибо если задача переключается не в момент "преступления", то ей за это ничего не будет .
Контроль по маркерам много более инфрмативен, нежели такое.

[AlexandrY]

Ну-ну продолжайте острить дальше. Память у Вас видно коротка (а не только в моём проекте), так хотя-бы почитайте весь тред.

Ладно, допустим вы даже читали про MPU.

В STM32F4 и STM32F7 оно действительно есть, хоть там дальше все равно идут нюансы с картой памяти, атрибутами доступа её областей и кэшированием свойственные только STM-ам.
А в Kinetis сделанных на том же Cortex-M4 ARM-овского MPU нет, а сделано свое MPU.

Или вот обычная практика для задач выделять стек в динамической памяти (ну для динамических задач), и эта же задача должна иметь доступ ко всей динамической памяти.
Т.е. задача не может взять и изолировать кусок в памяти поскольку должна иметь полное право писать и выше и ниже стека.
И все!
Красивая идея стухла и превратилась в костыль.

[jcxz]

А в Kinetis сделанных на том же Cortex-M4 ARM-овского MPU нет, а сделано свое MPU.

Пока Kinetis и STM не интересуют, интересуют TI и NXP главным образом.

Или вот обычная практика для задач выделять стек в динамической памяти (ну для динамических задач), и эта же задача должна иметь доступ ко всей динамической памяти.
Т.е. задача не может взять и изолировать кусок в памяти поскольку должна иметь полное право писать и выше и ниже стека.

В динамической памяти стеки задачам никогда не выделяю, все задачи живут постоянно - нет удаления задач.
При избытке памяти и "изолировать" ничего не мешает - выделить кусок заведомо большего размера, внутри него - выровненный на степени 2 регион1, закрыть его от доступа через MPU, внутри региона1 - регион2 меньшего размера - разрешить его для доступа (с бОльшим приоритетом чем у региона1). Регион2 расположен внутри региона1 так, чтобы между началом региона1 и региона2 и между их концами были некоторые защитные интервалы памяти.
Всё.
Но я уже сказал - облегчённые частные случаи типа: избыток памяти, избыток свободных регионов в MPU и пр. - не рассматриваю.

Тогда это делается очень просто, но больше для галочки,

Это точно.

[zltigo]

В динамической памяти стеки задачам никогда не выделяю, все задачи живут постоянно - нет удаления задач.

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