{"id":4268,"date":"2018-11-08T15:39:40","date_gmt":"2018-11-08T23:39:40","guid":{"rendered":"https:\/\/visualgdb.com\/w\/?p=4268"},"modified":"2020-05-05T17:12:35","modified_gmt":"2020-05-06T00:12:35","slug":"analyzing-the-stack-usage-of-your-firmware-with-visualgdb","status":"publish","type":"post","link":"https:\/\/visualgdb.com\/tutorials\/arm\/stack\/static\/","title":{"rendered":"Analyzing the Stack Usage of your Firmware with VisualGDB"},"content":{"rendered":"

This tutorial shows how to analyze the stack usage of your\u00a0ARM firmware using the VisualGDB’s static stack analyzer. We will create a basic FreeRTOS-based project\u00a0for the STM32F4-Discovery board, will analyze the stack usage by 2 threads, show how to explore the critical path and how to\u00a0account for cases like\u00a0dynamic function calls.<\/p>\n

Before you begin, install VisualGDB 5.4 or later.<\/p>\n

    \n
  1. Start Visual Studio and open the VisualGDB Embedded Project Wizard:\"01-newprj\"<\/a><\/li>\n
  2. Select “Create a new project” -> “Embedded binary”:\"02-binary\"<\/a><\/li>\n
  3. On the next of the wizard select your toolchain and the device:\"03-board\"<\/a><\/li>\n
  4. We will demonstrate the stack analysis under FreeRTOS. Unlike single-threaded projects where the stack automatically utilizes all available space between the end of heap and the end of RAM, RTOS-based projects require explicitly sizing\u00a0the stack for each thread, and hence are more prone to stack overflow.\u00a0Choose the “LEDBlink (FreeRTOS)” sample and click “Next”:\"04-sample\"<\/a><\/li>\n
  5. Connect your board to the USB port and let VisualGDB automatically detect the debug settings. Then press “Finish” to generate the project:\"05-stlink\"<\/a><\/li>\n
  6. Once the project is created, built it with Ctrl-Shift-B:\"06-project\"<\/a><\/li>\n
  7. Note how the RTOS-based projects require setting the stack size for each thread explicitly:\"minsize\"<\/a><\/li>\n
  8. Once the project is built, open the View->Embedded Memory Explorer\u00a0and\u00a0switch it to the static stack view:\"07-eme\"<\/a><\/li>\n
  9. The Memory Explorer will display\u00a0a list of all functions in your program and the stack\u00a0usage by each of them:\"08-mainstack\"<\/a>The stack usage is computed from analyzing the disassembly of each function, so it will also work for library functions. To make it easier account for rare\u00a0scenarios,\u00a0the code responsible for analyzing the stack-related effects\u00a0of each instruction runs in a separate open-source plugin<\/a>, so you can tweak it if your project uses\u00a0unconventional ways of\u00a0moving the stack pointer, or is not based on the ARM architecture.<\/li>\n
  10. Find the LED_Thread2 in the list and expand the critical path:\"09-criticalpath\"<\/a>VisualGDB will show that the\u00a0worst-case stack usage of the LED_Thread2()<\/strong>\u00a0function is 144 bytes (Max. stack column), that is actually larger than the 128 bytes allocated for the stack.\u00a0Each level of the critical path will show how much stack was already\u00a0used by the callers by the time a certain function was called (Stack on Entry column) and how much stack does each function itself use, not counting any called functions (Own Stack column).<\/li>\n
  11. Now we will try to reproduce the\u00a0worst-case scenario in debugger. Set a breakpoint in LED_Thread2()<\/strong> and try stepping in the functions along the critical path. Under normal circumstances, LED_Thread2()<\/strong>\u00a0will never run for long enough time to trigger the additional processing in xTaskResumeAll()<\/strong>\u00a0that lies on the critical path, so the\u00a0stack will never get overflown. However, adding a non-trivial interrupt handler later may affect the timing of the threads, trigger this branch and ultimately lead to a crash. We will simulate it by simply using the “Set Next Statement” command to step into the\u00a0block calling\u00a0xTaskIncrementTick()<\/strong>:
    \n    \"10-tick\"<\/a><\/li>\n
  12. Apply the same trick to step into uxListRemove()<\/strong> to get the worst-case stack layout in the debugger. Then switch the Embedded Memory Explorer to the Debug Stack view:\"11-structure\"<\/a>The Debug Stack view queries the exact locations of the stack frames in memory from the debugger,\u00a0visualizes them and displays detailed statistics. You can switch between frames to see the\u00a0variables and saved\u00a0registers contributing to the stack usage by each function. The white space between the variables is either lost due to alignment, or\u00a0could not be traced back to specific variables by the gdb debugger.<\/li>\n
  13. Now we will modify the LED_Thread1() function to dramatically increase its worst-case stack use. Add the following function to your code:\n
    void UseStack()\r\n{\r\n  volatile char buf[1024];\r\n  buf[0]++;\r\n}<\/pre>\n
    Then call it from LED_Thread1()<\/strong>:<\/p>\n
    if (rand() == 13)\r\n  UseStack();<\/pre>\n<\/li>\n
  14. As\u00a0the call to UseStack() is conditional (and the condition has a very low probability), dynamic analysis would likely not catch this. However as the\u00a0static analysis always considers the worst possible call sequence, it clearly shows that the stack use by LED_Thread1()<\/strong> has jumped to 1048 bytes:\"12-rarecase\"<\/a><\/li>\n
  15. Now we will complicate our scenario. Add the following global variable to your main file:\n
    void(*g_pFunc)();<\/pre>\n
    Update LED_Thread1()<\/strong> to set g_pFunc<\/strong> to UseStack() instead of calling it:<\/p>\n
    if (rand() == 13)\r\n  g_pFunc = &UseStack;<\/pre>\n<\/li>\n
  16. Finally call the\u00a0function pointer from LED_Thread2()<\/strong>:\n
    if (g_pFunc)\r\n  g_pFunc();<\/pre>\n<\/li>\n
  17. The stack analyzer won’t be able to\u00a0automatically unwind this, so it will show the stack usage for LED_Thread2()<\/strong> as 144, but will warn that it contains dynamic calls:
    \n    \"13-dynamic\"<\/a><\/li>\n
  18. One way to handle this automatically would be to extend the stack analyzer plugin<\/a> to check for possible values written to a certain variable, but that\u00a0would\u00a0still not cover all the cases. Instead, right-click on LED_Thread2()<\/strong> and select “Manually add calls from the selected function”:\"14-addcalls\"<\/a><\/li>\n
  19. Check the “UseStack” symbol and click “OK”:\"15-implicit\"<\/a><\/li>\n
  20. VisualGDB will\u00a0now recompute the stack usage for LED_Thread2()<\/strong> as if it directly called UseStack()<\/strong>:\"16-injected\"<\/a><\/li>\n
  21. VisualGDB stores the\u00a0manually specified calls in a text file called <Project Name>.stackrules. It\u00a0uses\u00a0a very straight-forward format, so you can generate\/update those rules programmatically:\n
    #This file stores explicit relations between functions\r\n#Format:\r\n#<function>:[<optional stack size override>]\r\n#<tab><called function>:[<optional stack usage at the time of call>]\r\nLED_Thread2\r\n  UseStack<\/pre>\n<\/li>\n<\/ol>\n
    You can find the\u00a0source code for the project shown in this tutorial in our tutorial repository on GitHub<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
    This tutorial shows how to analyze the stack usage of your\u00a0ARM firmware using the VisualGDB’s static stack analyzer. We will<\/p>\n","protected":false},"author":1,"featured_media":4287,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[27],"tags":[53,174,173],"_links":{"self":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/4268"}],"collection":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/comments?post=4268"}],"version-history":[{"count":4,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/4268\/revisions"}],"predecessor-version":[{"id":5999,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/4268\/revisions\/5999"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/media\/4287"}],"wp:attachment":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/media?parent=4268"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/categories?post=4268"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/tags?post=4268"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}