Как определить максимальное использование стека?

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

Именно так IAR IDE определяет количество используемого стека.

Вы отметили свой вопрос статическим анализом, но эту проблему сложно решить с помощью статического анализа. Использование стека зависит от профиля времени выполнения программы, особенно если вы используете рекурсию или alloca. Учитывая, что это встраиваемая платформа, я думаю, также сложно запустить что-то вроде ps или top и посмотреть, сколько стека использует ваше приложение.

Интересный подход - использовать адрес текущего кадра стека, чтобы определить, какой объем стека используется. Вы можете сделать это, взяв адрес аргумента функции или локальной переменной. Сделайте это для функции main и для функций, которые, по вашему мнению, используют наибольший стек. Разница подскажет, какой стек требуется вашему приложению. Вот пример (при обычном росте стека от высокого к низкому).

char *stack_top, stack_bottom;

int
main(int argc, char *argv[])
{
    stack_top = (char *)&argc;
    // ...
    printf("Stack usage: %d\n", stack_top - stack_bottom);
}

void
deeply_nested_function(void)
{
    int a;
    stack_bottom = (char *)&a;
    // ...
}

Если ваш компилятор позволяет вам указывать пролог пользовательской функции (многие делают это для профилирования программы на основе графа), вы даже можете настроить так, чтобы все функции вызывали такой измерительный код. Тогда ваша функция измерения будет выглядеть примерно так:

void
stack_measurement_function(void)
{
    int a;
    stack_bottom = min(stack_bottom, (char *)&a);
    // ...
}

Я использовал подход, аналогичный описанному мною, для создания этих диаграмм.

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

Под "хорошим" инструментом анализа я подразумеваю тот, который может читать все задействованные единицы компиляции, может определять прямые вызовы функций, может определять косвенные указатели в модуле компиляции, может вычислять консервативный анализ точек - по всей системе, может построить граф вызовов с учетом анализа точек. Это исключает использование множества инструментов, поэтому можно встретить специальные методы, такие как «заполнить стек во время выполнения и посмотреть, что произойдет». Вам также нужны оценки требований стека, которые компилятор помещает в стек; многое из этого можно приблизительно оценить, просто зная, насколько велики потребности в хранилище для всех типов, что обычно довольно легко определить для программ C встроенных систем. Наконец, вам нужно верить, что ваше приложение не имеет рекурсивных вызовов или что инструмент имеет представление о глубочайшей рекурсии (вероятно, по вашему сообщению).

DMS Software Reengineering Toolkit удовлетворяет всем этим требованиям для программ на языке C. См. http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html Вам по-прежнему необходимо настроить его для вычисления потребности в стеке путем сканирования графа вызовов и использования различных оценок размера.

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

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

Однако пара реализаций позволяет немного облегчить сложность:

(1) При использовании компилятора языка высокого уровня указатель стека в конце выполнения каждого оператора / строки кода должен находиться в том же месте, что и в начале. (По крайней мере, это хорошее правило, которое следует соблюдать, иначе у вас будут проблемы!)

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

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

Это не может быть выполнено до тех пор, пока все вызываемые функции также не будут скомпилированы. Поэтому я создаю файл для каждого скомпилированного модуля, в котором записывается количество размеров стека для каждого оператора (в основном пиковое значение перед каждым вызовом функции и значение непосредственно перед каждым вызовом функции (за исключением любых еще неизвестных добавлений к размеру стека, вызванных функцией call) и имена задействованных функций.Затем я ретроспективно обрабатываю эти файлы с помощью рекурсивной процедуры, как только все функции скомпилированы, чтобы определить пиковый размер стека.

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

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

Мне нравится давать подпрограммам прерывания свое собственное пространство стека в стеке ОС, если они нужны, чтобы они не добавляли к требованиям стека программ, кроме адреса возврата из прерывания.

• Не используйте рекурсию или рекурсивные алгоритмы никогда. (остерегайтесь библиотек регулярных выражений)
• Не используйте массивы, всегда используйте malloc ().
• Не используйте alloca (), у некоторых компиляторов даже есть ошибки в этой функции.

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

• Проверьте использование стека на подозрительной высокой точке в самом коде, войдите в интерфейс отладчика.
• Установите колпачок на основе предполагаемого использования стека с этим колпачком на месте. например ограничить серверные подключения.