0

I'm developing some software for microcontrollers, and I would like to be able to easily see which parts of the software are using how much memory. The software does not use dynamic memory allocation, I am only interested in static memory allocations (the bss and data sections).

All of this static memory is actually part of a single struct, which contains (most of the) memory the program works with. This is a hierarchy of structs, corresponding to the components of the program. E.g.:

struct WholeProgram { int x; struct ComponentA a; struct ComponentB b; }; struct ComponentA { int y; struct ComponentC c; struct ComponentD d; }; ... struct WholeProgram whole_program;

Ideally, I would like to see the memory usage represented with a multi-level pie chart.

I could not find anything that can descend into structures like this, only programs which print the size of global variables (nm). This isn't too useful for me because it would only tell me the size of the WholeProgram struct, without any details about its parts.

Note that the solution must not be in the form of a program that parses the code. This would be unacceptable for me because I use a lot of C++ template metaprogramming, and the program would surely not be able to handle that.

If such a tool is not available, I would be interested in ways to retrieve this memory usage information (from the binary or the compiler).

Ambroz Bizjak
  • 7,809
  • 1
  • 38
  • 49
  • Your example structs do not use any memory unless they are explicitly instantiated, and then it depends on how many instances you create. – Clifford Oct 05 '14 at 10:15
  • @Clifford I have a single instance of the root WholeProgram struct. – Ambroz Bizjak Oct 05 '14 at 10:19
  • You could simply examine/look at the .map file that results from the linking of the program to determine the sizing of each the segments of the program. – user3629249 Oct 06 '14 at 20:52
  • @user3629249 : That would in most linkers simply tell you the size of `whole_program` - that is not what is being asked. – Clifford Oct 09 '14 at 10:24

2 Answers2

1

Rather than using nm, you could get the same information (and possibly more) by getting the linker to output a map file directly. However this may not solve your problem - the internal offsets of a structure can be resolved by the compiler and the symbols discarded and therefore need not be visible in the final link map - only the external references are preserved for the purposes of linking.

However, the information necessary to achieve your aim must be available to the debugger (since it is able to expand a structure), so some tool that can parse your compiler's specific debug information - perhaps even the debugger itself - but that is a long shot, I imagine that you would have to write such a tool yourself.

The answers to GDB debug info parser/description may help.

Community
  • 1
  • 1
Clifford
  • 88,407
  • 13
  • 85
  • 165
0

If you declare instances of the component structs at global scope instead of inside the whole_program struct, your map file should give you the sizes of each component struct. Packing all the components into one single structure naturally results in only whole_program being listed in the map file.

TM_
  • 21
  • 8