Comprobación del uso de la pila en tiempo de compilación

StackAnlyser parece examinar el código ejecutable en sí más información de depuración. Lo que describe esta respuesta, es lo que estoy buscando, stack analyzer me parece exagerado.

Algo similar a lo que existe para ADA estaría bien. Mira esta página del manual del gnat:

22.2 Análisis del Uso de la Pila Estática

Una unidad compilada con-fstack-usage generará un archivo adicional que especifica la cantidad máxima de pila utilizada, en un base por función. El archivo tiene el mismo nombre de base que el archivo objeto de destino con una extensión. su. Cada línea de este archivo se compone de tres campos:

* The name of the function.
* A number of bytes.
* One or more qualifiers: static, dynamic, bounded. 

El segundo campo corresponde al tamaño de la parte conocida del marco de la función.

El calificador static significa que el tamaño del marco de la función es puramente estático. Normalmente significa que todas las variables locales tienen un tamaño estático. En este caso, el segundo campo es una medida confiable de la pila de funciones utilización.

El calificador dinámico significa que el tamaño del marco de la función no es estático. Sucede principalmente cuando algunas variables locales tienen un tamaño dinámico. Cuando este calificador aparece solo, el segundo campo no es una medida confiable del análisis de pila de funciones. Cuando se califica con acotado, significa que el segundo campo es un máximo confiable de la utilización de la pila de funciones.

No veo por qué un análisis de código estático no podría dar una cifra lo suficientemente buena para esto.

Es trivial encontrar todas las variables locales en cualquier función dada, y el tamaño de cada variable se puede encontrar ya sea a través del estándar C (para tipos incorporados) o calculándolo (para tipos complejos como estructuras y uniones).

Claro, no se puede garantizar que la respuesta sea 100% precisa, ya que el compilador puede hacer varios tipos de optimizaciones como relleno, poniendo variables en registros o eliminar completamente variables innecesarias. Pero cualquier respuesta que dé debería ser una buena estimación al menos.

Hice una búsqueda rápida en Google y encontré StackAnalyzer pero mi conjetura es que otras herramientas de análisis de código estático tienen capacidades similares.

Si desea una cifra 100% precisa, entonces tendría que mirar la salida del compilador o comprobarla durante el tiempo de ejecución (como Ralph sugirió en su respuesta)

Solo el compilador lo sabría realmente, ya que es el tipo que pone todas tus cosas juntas. Tendría que mirar el ensamblado generado y ver cuánto espacio está reservado en el preámbulo, pero eso realmente no explica cosas como alloca que hacen lo suyo en tiempo de ejecución.

Asumiendo que estás en una plataforma embebida, podrías encontrar que tu cadena de herramientas tiene una oportunidad en esto. Los buenos compiladores comerciales integrados (como, por ejemplo, el compilador Arm/Keil) a menudo producen informes del uso de la pila.

Por supuesto, las interrupciones y la recursión suelen estar un poco más allá de ellas, pero te da una idea aproximada si alguien ha cometido algún error terrible con un búfer de varios megabytes en la pila en algún lugar.

No es exactamente "tiempo de compilación", pero haría esto como un paso posterior a la compilación:

• deje que el enlazador cree un archivo de mapa para usted
• para cada función en el archivo de mapa, lea la parte correspondiente del ejecutable y analice el prólogo de la función.

Esto es similar a lo que hace StackAnalyzer, pero mucho más simple. Creo que analizar el ejecutable o el desmontaje es la forma más fácil de llegar a la salida del compilador. Mientras que el compilador sabe esas cosas internamente, yo me temo que no podrá obtenerlo de él (puede pedirle al proveedor del compilador que implemente la funcionalidad, o si usa el compilador de código abierto, podría hacerlo usted mismo o dejar que alguien lo haga por usted).

Para implementar esto necesitas:

• ser capaz de analizar el archivo de mapa
• comprender el formato del ejecutable
• saber cómo puede ser un prólogo de función y ser capaz de "decodificarlo"

Qué tan fácil o difícil sería esto depende de su objetivo plataforma. (Incrustado? ¿Qué arquitectura de CPU? Qué compilador?)

Todo esto definitivamente se puede hacer en x86/Win32, pero si nunca hiciste nada como esto y tienes que crear todo esto desde cero, puede tomar unos días antes de que haya terminado y tener algo funcionando.

No en general. El Problema de la detención en la informática teórica sugiere que ni siquiera se puede predecir si un programa general se detiene en una entrada dada. Calcular la pila utilizada para ejecutar un programa en general sería aún más complicado. Entonces: no. Tal vez en casos especiales.

Digamos que tiene una función recursiva cuyo nivel de recursión depende de la entrada que puede ser de longitud arbitraria y ya está fuera de suerte.