c++shared-librariesstatic-librariescallgrind

callgrind no source available for a couple of functions only


I am using linux and I am trying to debug an executable that I launch from the command line. It calls some functions from another custom library that I linked to it. I built both my executable and my library with the debug flags (-g3) then I ran it with callgrind this way:

valgrind --tool=callgrind --trace-children=yes ./my_exe --some_args

For most of the functions, kcachegrind shows the name and the location. But for a couple it just shows the address in hexadecimal format and complains about missing debug information. I just know that the functions come from my custom library.

The functions not being shown call some pthread functions (mainly pthread_mutex_lock and pthread_mutex_unlock) and are themselves called by other functions from the same library that are also not shown.

Despite that, I have some functions from my custom library that are fully displayed (name, file and even source code).

I tried compiling my_exe by linking dynamically my_lib.so:

kcachegrind displays the function location as being in my_lib.so but the name and the file of the function are not shown.

I then tried compiling my_exe by linking statically my_lib.a:

kcachegrind displays the function location as being in my_exe but once again it doesn't show the name nor the file and complains about missing debug infos. Other functions called from my_exe are also fully displayed as expected (name, file, source code...).

I don't understand why some functions would be displayed and some would not, given that they're in the same executable/library and that I compiled with debug symbols. I expected having either no function names at all or all of them. Am I missing some debug flags from valgrind ? Any ideas ?


Solution

  • Answering my own question in case it helps someone:

    I discovered that my custom library A was itself linked with another static library B and that the unsourced functions were arising from B. Since it was static, valgrind considered it as part of A.

    I managed to understand that by linking A dynamically with B (B.so), and valgrind told me the function was in libB.so. I could not find the exact name though since I don't have the sources to recompile lib B with debug flags but at least I was able to figure out where the problem was coming from.