Re: [Valgrind-developers] Re: MUL uInstr

[Jeremy F. <je...@go...>]

On Wed, 2002-10-02 at 11:33, Josef Weidendorfer wrote:
    What do you think about making data structure cost centers, and
    relating them to the functions? Even much more information available ;-)

You mean storing which code touches what memory as part of the profile? 
An excellent idea.
    
    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 each 
    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?

Well, it seems to me that the best name for an allocated block is some
portion of the stack backtrace leading to its allocation.  If you want
to parse the mangled names, you can easily tell what the class is, and
group all class instances together.  The object size should be easy - it
is the size of the allocated memory, surely?
    
    > 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. 
    Can gmon.out hold other events than sample counts?
    Do you log calls, too?

Yes, it can record a histogram (in any units/event types you like, but
the standard tools only generate time histograms), entry counts for each
basic block and BB to BB control flow counts.  gprof can display output
either on a function-by-function basis or at the basic block level
(including annotating source)
    
    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'm doing this work to instrument a piece of software which lots of
developers are working on, most of whom are familiar with gprof.

I also think most developers would welcome a friendly UI like
kcachegrind, so I'm very keen to try it out soon - I just want to get
the basics working first.
    
    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").

The gprof format could have been nice, but its somewhat broken.  They
extended it to be a tagged format so you can add extra sections - but
forgot to include a length with each tag, so you can't parse the file
unless you understand all the tag types.  A lost opportunity there.
    
    > 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...

Yes, but for now the code I'm instrumenting loads a lot of shared
libraries, but doesn't really unload or reload on the fly.

	J