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

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

Неужели нет никаких предположений ?

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

А map-файл GCC генерировать не умеет?

И что же такого про стек содержит map файл?

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

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

Это подойдёт?
Там же есть ещё другие варианты.

А совокупность возможных прерываний (и их комбинаций, в случае вложенности) как собираетесь подсчитывать?
В общем, брать надо с запасом.

Спасибо. Но к сожалению это только для GNAT.
Да, я в курсе.

Вот наткнулся на исследование, как раз прямо в яблочко. Проблема отлично исследована, я нашел ответы на все вопросы. Оказывается, есть и софт нужный, но так же есть и ньюансы.
http://www.cs.utah.edu/~regehr/stacktool/