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

Документы GCC:

-fstack-использование

Делает информацию об использовании стека вывода компилятора для программы для каждой функции. Имя файла для дампа создается добавлением .su к имени aux. auxname генерируется из имени выходного файла, если он явно указан и не является исполняемым файлом, в противном случае это базовое имя исходного файла. Запись состоит из трех полей:

• Имя функции.
• Количество байтов.
• Один или несколько квалификаторов: статический, динамический, ограниченный.

Квалификатор static означает, что функция управляет стеком статически: фиксированное количество байтов выделяется для кадра при входе в функцию и освобождается при выходе из функции; никакие другие настройки стека в функции не выполняются. Второе поле - это фиксированное количество байтов.

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

Я не могу найти никаких ссылок на -fcallgraph-info

Вы можете потенциально создать необходимую информацию из -fstack-usage и -fdump-tree-optimized

Для каждого листа в -fdump-tree-optimized найдите его родителей и просуммируйте их номер размера стека (учитывая, что это число относится к любой функции с динамическим, но не ограниченным) из -fstack-usage, найдите максимальное из этих значений и это должно быть ваше максимальное использование стека.

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

GCC 4.6 добавляет параметр -fstack-usage, который дает статистику использования стека для каждой функции.

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

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

Довольно поздно, но для всех, кто смотрит на это, ответы, содержащиеся в объединении выходных данных из fstack-usage и инструментов графа вызовов, таких как cflow, могут оказаться совершенно неверными для любого динамического выделения, даже ограниченного, потому что нет информации о том, когда этот динамический стек происходит выделение. Поэтому невозможно узнать, к каким функциям следует применить значение. В качестве надуманного примера, если (упрощенный) вывод fstack-usage будет следующим:

main        1024     dynamic,bounded
functionA    512     static
functionB     16     static

и очень простое дерево вызовов:

main
    functionA
    functionB

Наивный подход к их объединению может привести к тому, что main -> functionA будет выбран в качестве пути максимального использования стека, длиной 1536 байт. Но если самое большое динамическое выделение стека в main () - это передать большой аргумент, такой как запись, в functionB () непосредственно в стек в условном блоке, который вызывает functionB (я уже сказал, что это было надумано), тогда действительно main -> functionB - это путь максимального использования стека размером 1040 байт. В зависимости от существующего программного обеспечения, а также для других целей с более ограниченным доступом, которые передают все в стеке, кумулятивные ошибки могут быстро привести вас к поиску совершенно неправильных путей, требующих значительно завышенных максимальных размеров стека.

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

Короче говоря, вы должны быть предельно осторожны при использовании этого подхода.

В итоге я написал сценарий на Python для реализации ответа от τεκ. Слишком много кода для публикации здесь, но его можно найти на github.

Я не знаком с параметрами -fstack-usage и -fcallgraph-info. Однако всегда можно выяснить фактическое использование стека:

1. Выделите достаточное пространство стека (для этого эксперимента) и инициализируйте его чем-нибудь легко идентифицируемым. Мне нравится 0xee.
2. Запустите приложение и проверьте все его внутренние пути (по всем комбинациям входных данных и параметров). Дайте ему поработать более чем «достаточно долго».
3. Изучите область стека и посмотрите, какая часть стека была использована.
4. Установите размер стека плюс 10% или 20%, чтобы допускать обновления программного обеспечения и редкие условия.

Обычно существует два подхода - статический и динамический.

Статический: скомпилируйте свой проект с -fdump-rtl-expand -fstack-usage и из *.expand скрипта получите дерево вызовов и использование стека каждой функции. Затем переберите все листья в дереве вызовов и вычислите использование стека в каждом листе и получите максимальное использование стека. Затем сравните это значение с доступной памятью на цели. Это работает статически и не требует запуска программы. Это не работает с рекурсивными функциями. Не работает с массивами VLA. В случае, если sbrk() работает с разделом компоновщика, а не с предварительно выделенным статическим буфером, он не принимает во внимание динамическое выделение, которое может увеличиваться само по себе с другой стороны. В моем дереве есть сценарий , stacklyze.sh, с которым я исследовал этот вариант.

Время выполнения: до и после каждого вызова функции проверяйте текущее использование стека. Скомпилируйте код с -finstrument-functions. Затем определите две функции в своем коде, которые примерно должны получить текущее использование стека и работать с ними:

static unsigned long long max_stack_usage = 0;

void __cyg_profile_func_enter(void * this, void * call) __attribute__((no_instrument_function)) {
      // get current stack usage using some hardware facility or intrisic function
      // like __get_SP() on ARM with CMSIS
      unsigned cur_stack_usage = __GET_CURRENT_STACK_POINTER() - __GET_BEGINNING_OF_STACK();
      // use debugger to output current stack pointer
      // for example semihosting on ARM
      __DEBUGGER_TRANSFER_STACK_POINTER(cur_stack_usage);
      // or you could store the max somewhere
      // then just run the program
      if (max_stack_usage < cur_stack_usage) {
            max_stack_usage = max_stack_usage;
      }
      // you could also manually inspect with debugger
      unsigned long long somelimit = 0x2000;
      if (cur_stack_usage > somelimit) {
           __BREAKPOINT();
      }
}
void __cyg_profile_func_exit(void * this, void * call) __attribute__((no_instrument_function)) {
      // well, nothing
}

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

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

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