Как определить размер стека для задачи в RTOS ?, в gcc Опции

[artymen]

Первый раз использую RTOS. Сейчас размеры стеков для каждой задачи я прикинул на глаз. По мере того, как система начинает вести себя откровенно неадекватно, я увеличиваю их, но памяти остается все меньше и меньше. Есть конечно всяческие макросы и функции для отслеживания стека и его переполнения, но ведь есть определенная вероятность того, что они соврут при возникновении переполнения. Очевидно, правильнее всего решать эту проблему еще на этапе компиляции, до отладки. (Мне так кажется.) Но по С/С++ коду "вычислить на глаз" требуемый стек не всегда возможно, если, например, происходит обращение к функциям из третьесторонних библиотек, и уж тем более, если они не имеют исходных кодов, а линкуются, да и куда там, надо еще знать, какие эпилоги к функциям генерирует компилятор...
Вопрос. Есть ли в GCC средства, чтобы прогнать всевозможные ветви выполнения заданной функции и определить самую глубокую точку, которой достигает стек ?
Меня интересует больше общий подход и методика, поэтому конкретную ось и микроконтроллер не называю, но если интересно: FreeRTOS (адаптированный порт ATMega323) и ATMega128.

P.S. Если уж на то пошло, подскажите какой-нить обзор по инструментам gcc (м.б. bintools ?), а то как открою директорию bin и сразу воображению предстают всякие мощные и гибкие возможности, которыми я не владею

Сообщение отредактировал artymen - Nov 5 2010, 15:33

[artymen]

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

FreeRTOS, например, сама заполняет. И остлеживает переполнение, похоже, тоже этим методом, однако 100% гарантии нет. Еще раз повторюсь: я убежден, что по-нормальному это надо делать еще на этапе компиляции.

А в IAR EW430, например, map-файл содержит описания для каждой функции, в которых указано использование данной функцией стека и вызовов ею других функций. Также в map-файле можно посмотреть граф вызовов функций с утилизацией ими стековой памяти.

А вот это интересно ! Не может быть, чтобы gcc этого не умел...

Сообщение отредактировал artymen - Nov 18 2010, 14:14