4

I'm currently trying to analyze and debug performance issues of a library I'm using. For this reason, I wrote a short C++ code that would use some of the core features of this library and run a simple timer on it.

In order to dive a bit deeper, I now started using valgrind with the --tool=callgrind option. I visualize the results using kcachegrind. I have done this before and know (in principle) how this works.

However, I was very surprised to see a pattern like this:

main
  |
myfunc()
  |
_dl_runtime_resolve_xsave

After this, the call graph just stops, even though I can seem many more low-level functions in the list.

I believe that this structure of the call graph might be related to the library using multiprocessing, for which I haven't used valgrind before. However, using google, I was unable to find explanations for this specific function call.

Can someone explain to me what I'm seeing here, and why the call graph is seemingly disconnected at this function call?

carsten
  • 1,315
  • 2
  • 13
  • 27
  • I see similar `_dl_runtime_resolve_*` and very small call graphs in the project I'm debugging. There is a button on the toolbar, "Cycle Detection". Disabling it shows graphs which make much more sense. All functions seem to call into that `_dl_runtime_resolve` which adds noise but if you ignore it, the call graph is actually useful. – SnakE Oct 09 '18 at 22:35

1 Answers1

2

I think those "_dl_runtime_resolve*" functions are called when you are loading a shared library into your program. I usually see one of those in every library function, called only once or twice. I'd just ignore them.

Max Wittal
  • 21
  • 2