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

[Nicholas N. <nj...@ca...>]

On Fri, 4 Oct 2002, Josef Weidendorfer wrote:

> The only problem I saw was that I need a valgrind version of the LIBC
> "unlink", which I already mailed to Nick...

I just added VG_(unlink) to head;  it's untested, hopefully I got it
right.

> Regarding the valgrind skin architecture: Shouldn't it be possible to "stack"
> skins? At the moment, for my skin I have to include all the cachegrind code
> again. And if the cachegrind skin decides to simulate a 3rd level cache, I
> have to copy it.

Hmm, the LD_PRELOADing of two shared objects (skin.so + core.so) is
already a bit fragile, having multiple .so's feels like a bad idea to
me...  Anyway, aren't Cachegrind and your patched version dissimilar
enough that it wouldn't be easy to "stack" them in a sensible way?  A
better way might be to factor out the common code which gets included in
both skin .so's, if you see what I mean.  This should be done with
addrcheck and memcheck at some stage because they share a lot of identical
code.

Thinking longer term, your version of Cachegrind could entirely replace
the original Cachegrind one day, since AFAICT your Cachegrind's
functionality is a strict superset of my Cachegrind's.

> In fact: Call tree logging should be totally orthogonal to event
> logging. Shouldn't we have some general support for expandable cost
> centers in the core?

Maybe, I thought about this but didn't get any further.  If would help if
you could give some specific suggestions as to the form it might take.

> 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.
> [...]
> Suggestions?

My brain is melting.  Do you know how gprof handles it?

N