Re: [Valgrind-developers] Re: MUL uInstr

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

Hi,

just want to say hello to the Valgrind Developers mailing list...

On Wednesday 02 October 2002 18:04, Jeremy Fitzhardinge wrote:
> On Wed, 2002-10-02 at 04:31, Nicholas Nethercote wrote:
>     As for gprof stuff, have you seen Josef Wiedendorfer's Cachegrind pat=
ch
>     and KCachegrind visualisation tool?=20
> (www.weidendorfers.de/kcachegrind/) It contains loads of that sort of
> thing, more than my brain can handle in one sitting :)

What do you think about making data structure cost centers, and
relating them to the functions? Even much more information available ;-)

More serious: With C++, you have constructors, and that's a nice way
to name malloced areas. Together with some debug info, it should be easy
to give out a list of all C++ classes, and read/write access numbers for ea=
ch=20
offset (or with annotated class definition from source).
If the constructor is defined in a shared lib (as for all QT/KDE classes), =
you
don't even need debug info for this: The object start address is always the
first arg to the constructor, only question: how to detect the object size?

> I looked at the screenshots and decided it is very pretty, but I haven't
> actually tried it out yet.
>
> I've actually done a first cut of a gprof skin now, which generates
> correctly formed gprof gmon.out files.  Unfortunately gprof itself is
> too broken to deal with them (it wants a single histogram array for the
> whole address space; I'm teaching it to work with a sparse array).

Cool.
Sorry, I couldn't follow the discussion.=20
Can gmon.out hold other events than sample counts?
Do you log calls, too?

I'm not quite sure I understand the benefit of creating gmon.out files.
Are there other frontends for this format than gprof?
(There's a KProf, but that "only" shows the info from gprof).
I want to add a gmon.out reader for KCachegrind some day for
quick browsing and TreeMap generation for gprof-profiled apps.

I think the cachegrind.out format is quite nice:
Although I added a lot, I still can read the original cachegrind.out
files without problem.
Nick: Can you add some versioning to this format to distinguish
some format variants?
(I added a line "version: xxx").

> I'm also going to extend the core slightly; I'd like to add some way of
> extracting more information about the segments described in the SegInfo
> list.  I'd like to be able to walk the list so I can include a table of
> mapped shared objects and what address range they cover.

A problem here could be the dynamic behaviour of mappings...

>
>     J
>

J :-)