I'm using ESP-IDF v3.1.2 trying to use the -fstack-usage compiler flag. I'm basically trying to achieve what this page explains https://mcuoneclipse.com/2015/08/21/gnu ... -analysis/. I want this compiler flag to optimize the stack usage of my tasks because in large and complex codebases the usual uxTaskGetStackHighWaterMark() method to optimize the stack usage is time-consuming and error-prone.
I have added the -fstack-usage to my components CFLAGS but when compiling the .su files are not being generated. Does the XTensa GCC support the -fstack-usage? I cannot find any information about this.
-fstack-usage support
Re: -fstack-usage support
This is very neat, how do I not know this feature existed!?
I was able to get .su files for a component's source files with the following additions to component.mk (for GNU make based build system):
(Reference)
And the following addition to CMakeLists.txt (for CMake based build system):
(Reference)
Note that, as the linked blog post explains, some additional scripting magic is required to find total static call stack stack usage, rather than individual function's' individual stack. There is an extra complexity for ESP-IDF applications because some functions are in the ESP32 ROM (including the default implementations of printf and scanf, which are big stack hogs). And I assume there's no way to measure static stack usage of a recursive function, although most ESP-IDF apps probably don't have a lot of these![*]
There might be some tooling we can do to make this easier in ESP-IDF (including providing .su files for the ROM, maybe).
[*] Edit: on a moment's further reflection there are a bunch of things C can do - function pointers for one - which probably make reliable static stack measurement hard in a lot of cases. But may still be useful for calculating simple call stack overheads.
I was able to get .su files for a component's source files with the following additions to component.mk (for GNU make based build system):
Code: Select all
CFLAGS += -fstack-usage
And the following addition to CMakeLists.txt (for CMake based build system):
Code: Select all
component_compile_options(-fstack-usage)
Note that, as the linked blog post explains, some additional scripting magic is required to find total static call stack stack usage, rather than individual function's' individual stack. There is an extra complexity for ESP-IDF applications because some functions are in the ESP32 ROM (including the default implementations of printf and scanf, which are big stack hogs). And I assume there's no way to measure static stack usage of a recursive function, although most ESP-IDF apps probably don't have a lot of these![*]
There might be some tooling we can do to make this easier in ESP-IDF (including providing .su files for the ROM, maybe).
[*] Edit: on a moment's further reflection there are a bunch of things C can do - function pointers for one - which probably make reliable static stack measurement hard in a lot of cases. But may still be useful for calculating simple call stack overheads.
-
- Posts: 6
- Joined: Thu Jan 31, 2019 2:53 pm
Re: -fstack-usage support
Thank you! That did the jobESP_Angus wrote: ↑Thu Jan 31, 2019 11:08 pmThis is very neat, how do I not know this feature existed!?
I was able to get .su files for a component's source files with the following additions to component.mk (for GNU make based build system):
(Reference)Code: Select all
CFLAGS += -fstack-usage
And the following addition to CMakeLists.txt (for CMake based build system):
(Reference)Code: Select all
component_compile_options(-fstack-usage)
Note that, as the linked blog post explains, some additional scripting magic is required to find total static call stack stack usage, rather than individual function's' individual stack. There is an extra complexity for ESP-IDF applications because some functions are in the ESP32 ROM (including the default implementations of printf and scanf, which are big stack hogs). And I assume there's no way to measure static stack usage of a recursive function, although most ESP-IDF apps probably don't have a lot of these![*]
There might be some tooling we can do to make this easier in ESP-IDF (including providing .su files for the ROM, maybe).
[*] Edit: on a moment's further reflection there are a bunch of things C can do - function pointers for one - which probably make reliable static stack measurement hard in a lot of cases. But may still be useful for calculating simple call stack overheads.
Yes, ROM functions and function called through pointers will still need to be considered apart but I think it could be useful to have a general idea of the stack usage or almost a complete stack usage analysis in simpler tasks. Providing the .su files for the ROM functions would be awesome!
Who is online
Users browsing this forum: No registered users and 216 guests