Re: [Valgrind-users] How to make function names visible?

[Josef W. <Jos...@gm...>]

On Wednesday 28 October 2009, Andreas wrote:
> I'm using callgrind to profile an application which is using the GSL 
> library.
> 
> I run valgrind using
> 
> $ valgrind --tool=callgrind ./getStrat_single
> 
> and inspect the resulting callgrind.out.PID file with kcachegrind.
> 
> In the output I can see that 24% time is taken by the function 
> gsl_interp_eval(). For this function I can see exactly one callee, which 
> is named 0x000000000009ef80. Now I searched a bit in the GSL sources and 
> found that inside gsl_interp_eval(), the following happens:
> 
> int status = interp->type->eval (interp->state, xa, ya, interp->size, x, 
> a, &y);
> 
> This eval() points to the function cspline_eval(). Inside 
> cspline_eval(), there is one call to another function 
> gsl_interp_accel_find() as well as a call to coeff_calc(), an inline 
> function. Now I would be really interested in knowing how the 24% of 
> time that gsl_interp_eval() takes is distributed between coeff_calc(), 
> gsl_interp_accel_calc() and the non-funtion-call-code inside 
> cspline_eval(). So my question is: How can I get callgrind to give me 
> this information?

Let me try to understand your question: you have two functions with the
compiler inlining one into the other. So there is actually only one
function left in the binary, but you would like to see the self cost of
both original functions as separate values (I did not exactly understand
the call relationship of mentioned functions in GSL).

In theory, one can use the line debug information that is provided with
every instruction to relate the costs to the inlined function vs. the
calling function. In KCachegrind's source annotation view, you should
see both functions with one prefixed by a line saying something about
inlining. What is missing is a way to select multiple lines and get
the sum of self costs of selected lines. I already got a similar request
a while ago, and it should be easy to do.

But... by inlining, the compiler can do a lot of optimizations where resulting
assembly code can not be related back to one or the other function, so I suppose
part of the line debug information can very well be bogus.

So in short: you need to sum up numbers in the source annotation view of
KCachegrind yourself (or change the callgrind output in a way to make two
functions out of it by separating code according to file/line numbers).

But a better solution would be to recompile GSL to not do inlining at all
(with potentially lost optimizations).

Josef