|
From: Josef W. <Jos...@gm...> - 2002-10-14 11:15:27
|
Hi Jeremy, I just looked over your vgprof skin: Seems quite cool :-) The client side requests (e.g. VALGRIND_DUMP_PROFILE) are quite useful. But they need changing source and recompilation. Did you already thought about alternate solutions? I have the "--dumpat=3D" command line option (should be renamed to=20 --dump-at-entering=3D" and adding "--dump-at-leaving=3D"). Additionally I allow interactive controlling a cachegrind run by creating "cachegrind.cmd" files. At the moment, simply a dump is made when detecting this file. But I want to add commands for cachegrind to read an= d execute them, e.g. "DUMP NOW" or "DUMP AT ENTERING xxx" or "DELETE DUMP AT ENTERING xxx". It would be cool if we could come up with some kind of "standard" for thi= s. Especially as I would like to add a (v)gprof import filter for KCachegrin= d,=20 and you create trace parts, too: KCachegrind has a toolbar button "force=20 dump", creating a "cachegrind.cmd" file (This should be renamed to=20 "valgrind.cmd"). The idea of different "weights" for different instructions seems to be quite useful to add to cachegrind (as new event type). How did you get your weights? They can be quite different for every different processor (AMD/Intel). And the best thing would be to get the values by measuring online, with an additional tool to put measured weights into a config file (like=20 calibrator for the cache latencies). As I understand, you have a new gmon format version. I would suggest the following for the new format: For each header, add a section length field to allow skipping this section if the reader doesn't know about the section type (You once said = that=20 this is a shortcoming of the current format yourself). Multiple history sections seem to be supported in the format. Can (v)gpro= f=20 handle these, e.g. choosing them per option? Or does the gprof output hav= e=20 different columns for each event type? I would like to add an gprof import filter to KCachegrind: Supporting an=20 extensionable format would be good for this. I suppose I will have to cop= y=20 all the symbol reading stuff from binutils. The nice thing of the cachegr= ind=20 format is that you already have symbol names... If I understand correctly, you associate the weights of a BB to the start= =20 address of this BB. Is this granularity enough for annotated source outpu= t of=20 your vgprof? I suppose if you have a series of non-branching statements on a few sourc= e=20 lines, the annotation would put all the weights to the source line of the= =20 first statement... On Monday 14 October 2002 07:53, Jeremy Fitzhardinge wrote: > Here's a series of my patches against the current Valgrind CVS head. > They are: > [...] > 12-vgprof > A skin which generates gprof-style profiling output files. This al= lows > profiling of multithreaded programs using shared libraries. Requir= es a > patched version of gprof to interpret the output files. |