[Valgrind-developers] Re: kcachegrind patch for valgrind-HEAD?

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

Hi,

On Friday 04 October 2002 03:01, Jeremy Fitzhardinge wrote:
> Hi,
>
> Do you have a patch for the current CVS version of valgrind?  I finally
> got enough of KDE installed on my laptop to compile kcachegrind, so I'm
> keen to try it out.
>
> Thanks,
> 	J

Sorry: I don't have much time at the moment...
Last wednesday I looked for the first time at valgrind-HEAD. It seems to be=
=20
quite easy to port my patch to a skin. The only problem I saw was that I ne=
ed=20
a valgrind version of the LIBC "unlink", which I already mailed to Nick...=
=20

Regarding the valgrind skin architecture: Shouldn't it be possible to "stac=
k"=20
skins? At the moment, for my skin I have to include all the cachegrind code=
=20
again. And if the cachegrind skin decides to simulate a 3rd level cache, I=
=20
have to copy it. In fact: Call tree logging should be totally orthogonal to=
=20
event logging. Shouldn't we have some general support for expandable cost=20
centers in the core? Then I could use these to add/subtract costs without=20
even knowing which ones are logged...
To be honest, I didn't thought much about this idea yet...

Regarding KCachegrind: I still have a problem with visualizing recursive=20
calls. This seems to involve changes in the Cachegrind patch, too.
So I first have to solve this one before I'm making any new patch/release...
Aside from that: I switched to GCC 3.2 with an update to Suse 8.1, and now
I have a lot of problems with lost debugging info :-(

Question: What are the exact problems with GCC 3.x, that it's not officiall=
y=20
supported in Valgrind ?


Perhaps you have some suggestions for my problem with recursive calls:

Suppose a call chain starting from A: A calls B and C; C calls A again. The=
=20
recursively called A only calls B. Say the cost of B is always 100, the sel=
f=20
cost of each A and C are 10. So the cumulative cost of C will be 120=20
(C=3D>A=3D>B), and the one of the first call to A will be 230. I log (cumul=
ative)=20
costs for the call A=3D>B only once, so this call gets cost 200.
The problem: The callee list of A shows a call to B with cost 200 and a cal=
l=20
to C with cost 120, but A itself only has cumulative cost 230 !?! This is=20
confusing to the user, and really makes problems drawing the TreeMap...
The real problem is that KCachegrind can't see that the cost of A=3D>B is=20
included in the call cost A=3D>C and thus shown twice in the callee list of=
 A.
And in the Treemap, I simple stop drawing recursive calls: This leaves empty
space where there should be none and it looks like a performance problem for
the user where there is none !!

The first ad-hoc solution was to distinguish among calls from recursively=20
called functions, i.e. the 2 calls A=3D>B will be logged independent from e=
ach=20
other: this makes the example looking quite fine again.
But this makes the real problem disappear for a few simple examples (as the=
=20
above one) only; it's still there for deeper recursions, and cumulative cos=
ts=20
of calls always include ALL recursion costs inside of this call: I log the=
=20
cost counter difference at entering/leaving the function.

The real solution (without the ad-hoc one) would be:
The callee list of A shows a call to B with cost 200. This is correct: B is=
=20
called twice from A, leading to cost 200 for calls to B. But the call A=3D>=
C=20
should be 20 only, skipping costs from any recursive A inside (perhaps=20
stating that cost 100 is already included in other calls). And this would=20
make the Treemap drawing fine again.

So the only question I have:
HOW to calculate this value (20) in the general case ?!?
I suppose I can't calulate it at post-processing time, but have to log it i=
n=20
Cachegrind somehow (that is, the skipped cost of 100 in the example above).

Suggestions?

Josef