Няма анализатор който да може да се оправи като хората с указатели към функции и от там нататък имаш два варианта:
- или не ползваш въобще указатели към функции (включително неявното им ползване като виртуални методи)
- или не анализираш дълбочината на стека

Вариантът в който анализираш само доколкото може пък където не може не анализираш не ми се струва особенно удачен.

Това с читавата система за мониторинг няма как да го избягаш защото ти хваща и куп други проблеми - забили нишки, препълване на стека, разни логически грешки които не бива да се случват (асерти и т.н.) т.е. все неща които няма как статично да ги анализираш. То като се замислиш там където може да се анализира самият компилатор го прави и ти оптимизира кода а там където не може всига ръце и не пипа, че да не омота нещо.

Статичният анализ не е много далеч от halting теоремата, така че оптимизмът в тая посока не е оправдан.

Практичните подходи остават за runtime, както и palavrov казва. Ако имаше MMU лесно можеше да изолираш стековете от двете страни, ама подозирам че си с някое смотано ARM MPU, от което файда няма.

Огледай https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html за "-finstrument-functions" - да си сложиш викания на собствени профилиращи функции в пролога/епилога. Има и купчини проверки на тема стек и какво ли не, но ми изглеждат със съмнителна стойност.

Не, задачата е по-елементарна от halting теоремата. Пък е и факт че има статични анализатори. Сега съм малко отпуска и другата седмица ще поровя още...
За нуждите на стек анализа не е необходима 100% точност. Примерно честа ситуация с виртуалните методи е да се зареждат обекти от файл или от някъде отвън. Четеш типа и създаваш един или друг обект и му викаш load(). Статичният анализатор няма как да знае какви ще са данните, но него го интересува максималния стек, т.е. достатъчно е да се знаят всички класове и всички наследявания. А те се знаят в повечето компилатори, така че просто се взема варианта на load() дето яде най-много и толкоз. По-точно търси се се най-дългия път, но това са подробности.
Да, статичния анализ няма да е 100% точен, но грешката му е в презапасяването, т.е. ще сметни по-голям стек от нужното. Това обаче не е фатално, известен преразход на памет не ме притеснява, притеснява ме недостига
Иначе, да може да се напише код, който трудно би се анализирал... но сме му яли попарата и вече го избягваме тоя стил щото не само анализатора и ние се бъркаме и не можем да го поддържаме.