байтах)?
Считаем выражение, ходим в дерево. Оно внезапно может оказаться очень глубоким (выражение пришло снаружи).
Мы можем прикинуть размер стека по высоте дерева, но для этого нужно знать, сколько занимает один шаг.
Вручную я могу прошагать в дебаггере на пару шагов и посмотреть разницу двух снимков $rsp. И даже могу захардкодить эту константу… Но потом другой уровень оптимизации, другой компилятор, другая платформа и т.д. делают такое измерение очень хрупким.
Можно и замокать - создать на стеке какой-нибудь паттерн, потом вызывать обход, постепенно увеличивая глубину, и смотреть, как портится паттерн. Это работает, но это жуткий хак. Санитайзеры/валгринды радостно пищат про access-after-use. Ну и в целом, оно же должно быть известно в compile-time. Адрес возврата и frame-pointer известны; распределение места для локальных переменных компилятор тоже знает…
Ну берешь у себя в мейне заводишь переменную, берёшь её адрес, потом в своём коде берешь адрес другой переменной локальной и вычитаешь адреса
Ну и в целом, оно же должно быть известно в compile-time. Адрес возврата и frame-pointer известны; распределение места для локальных переменных компилятор тоже знает вы упускаете существование alloca
На сколько я знаю в .eh_frame секции ELF объектного файла складывается аннотация кода в виде CFA программы. Это последовательность dwarf инструкций которые описывают состояние фрейма и регистров вдоль кода. CFA программа используется для раскрутки стека при пробросе исключений и для отладки оптимизированного кода. В libgcc_s есть код интерпретирующий её для unwind-а.
Обсуждают сегодня