gprof for non-native boards

Hi, for stack memory optimizations in GNRC I need some kind of tool to analyze the call-path of its threads (the stackusage of each function itself can easily determined using GCC [1]). After some experiments with some static solutions (I basically went through the list here [2]) I wasn't able to come to a satisfying result, so I want to go for a run-time solution. However, we have (undocumented) support for gprof on native [3]. Has anyone experience with gprof on non-native boards? What tools do I need to install besides the respective gprof-version? How do I connect gprof to the board?

Cheers, Martine

[1] https://gcc.gnu.org/onlinedocs/gnat_ugn/Static-Stack-Usage-Analysis.html [2] https://en.wikipedia.org/wiki/Call_graph#Free_software_call-graph_generators [3] https://github.com/RIOT-OS/RIOT/blob/master/boards/native/Makefile.include#L156-L159

Hey,

Has anyone experience with gprof on non-native boards? What tools do I need to install besides the respective gprof-version? How do I connect gprof to the board?

I've tried to set it up but didn't succeed after a couple of hours. Gprof needs it's augmentation to be initialized, and at some point (usually at program exit) it's data needs to be written down (or sent via serial/...).

My problem was a severe lack of documentation on how to set up the framework for using gprof in baremetal contexts.

Since then a lot happened, and a while ago I found this [1], which looks like it could be adapted to RIOT.

+1 for digging into this!

Kaspar

[1]

Hi Martine,

if your just interested in the call path and speed is no concern, I imagine that you could implement this relatively easy on your own. GCC can generate hooks for each function call [1] that you could use to print directly via serial and later resolve names using the linker map file.

However, you won't be able to get meaningful benchmarks as this would slow down the code *a lot*. Still, if you're interested in statistics about which functions your code visted the most, kCacheGrind is a nice tool for visualization with a really simple syntax.

Not long ago I needed a profiler for an x86 OS (no Linux!) and also had a look at gmon/gperf. At that time, it seemed easier to integrate XRay [3] into my project, but I guess this will not fit for an embedded target.

Cheers, Daniel

[1] https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Code-Gen-Options.html#index-finstrument_002dfunctions-1625 [2] https://kcachegrind.github.io/html/Home.html [3] https://chromium.googlesource.com/chromium/src/+/master/native_client_sdk/src/libraries/xray

Hi Martine!

for stack memory optimizations in GNRC I need some kind of tool to analyze the call-path of its threads (the stackusage of each function itself can easily determined using GCC [1]). After some experiments with some static solutions (I basically went through the list here [2]) I wasn't able to come to a satisfying result, so I want to go for a run-time solution. However, we have (undocumented) support for gprof on native [3]. Has anyone experience with gprof on non-native boards? What tools do I need to install besides the respective gprof-version? How do I connect gprof to the board?

I used gcc's --finstruments-functions for my work on energy profiling some years ago. Together with Stefan Pfeiffer we also toyed around with it to determine the stack usage of certain functions. Some fragments of this can be found in my repository:

If you don't care for the performance impact, you could use this for dumping the call-path, too, I guess.

Cheers, Oleg

Hi, thank you all a lot! Since performance isn't really an issue (as I said: I just want to get the call-graph of each thread), I guess `--finstruments-functions` is the way to go.

Cheers, Martine

Hi,

I just want to throw in instrumental [1,2] by Sebastian Krahmer, who to my knowledge was one of the first to toy around with the finstrument options.

Best, Michael

[1] http://users.suse.com/~krahmer/instrumental/instrumental.pdf [2] http://users.suse.com/~krahmer/instrumental/