|
From: Bryan M. <om...@br...> - 2006-08-07 20:21:41
|
Josef,
more comments below.
Bryan
Josef Weidendorfer wrote:
> On Monday 07 August 2006 01:32, Bryan Meredith wrote:
>> One thing of note - I set the context in kcachegrind to be 50 so that in
>> effect, the whole of the file is displayed. The display goes past the
>> end of the file.
>
> Oops :-)
>
>> I shall download the latest source (really not sure
>> what version I am running) and see if I can put a patch together for you
>> to consider. There is also the issue of showing source files that don't
>> get hit at all - maybe there is some scan that could be run from a menu
>> option for that? I don't know. I will look at this as well.
>
> I really would suggest to generate a file with the event "lineWithCode"
> (either within a Covergrind run, or offline), and load this into KCachegrind
> with the original data. Currently, you have to use "File/Add" to merge
> data files within KCachegrind (or use a special naming, like Callgrind is
> doing for parts of one profile run).
I was thinking of two cases here: source files that are compiled but not
linked and source files that aren't even compiled. Being able to flag
these files (large projects can often end up with this sort of "fluff"
lying around) would assist further in cleanup / test development.
>
> Unfortunately, this merging will always default to add event counts, which
> is wrong for coverage: If in run 1, function foo has 20 lines touched, and
> in run 2, there are 15 lines touched, the merge will show 35 lines touched.
> It would be better for merging to specify other reductions for events types
> like min/max etc.
>
> With "lineWithCode", the problem to show huge context should be gone.
A "show entire file" option might be a nice alternative?
>
>> The "ignores some files" thing is because I can only have 499 items in a
>> list box.
>
> ??
> Sorry, where does this limitation come from? Are you talking about
> Covergrind or KCachegrind?
KCachegrind: the list box in the bottom left shows something along the
lines of "ignoring X files < Y". By increasing the list box size in the
options dialog up to 499 on my small test run, this problem goes away.
The 500 limit is way to small for some of the stuff I intend to run this on.
>
>> This is going to be a major headache at work where the file
>> count is well above 1000 (and probably at least 2000).
>
> Hmm, shouldn't be a problem.
It should handle the files, I just wont be able to select them all
because the list box wont display more than 499.
>
>> I shall have another read through the source for the debug information
>> parsing. I don't want to do anything whilst the program is running
>
> Getting this debug information once for an ELF object should be neglectable
> in a Valgrind run. If you are doing multiple runs (regression tests) in a row
> on the same binary, you could add a command line option to do it only once.
>
> However, the current Valgrind Tool API for debug information can not
> simply iterate over info in a given address range, but you have to
> request debug info for every address, which will interally do a
> binary search again and again. Still, it should work reasonable fast.
If it is doing a binary search, (without looking at the code) it might
be possible to adapt it / generate another function to walk part of the
list / tree, calling a passed in function pointer or some such. I will
have a look at this as simple access to the results of the parsing
output but in a linear format based on source lines would be really
useful. I will see what I can do and post some patches for people to
laugh at :D
The new functionality could possibly even return something like:
struct lines {
int size;
char *bits;
}
where size is the amount of memory malloced onto bits and bits are set
based upon line number:
bits[line_num / (sizeof(char) * 8)] |=
(1 << (line_num & (((sizeof(char) * 8) - 1)));
For the processing overhead, you end up with a pretty compact
representation of the lines with code on them. Maybe this could be
cached and a pointer to it be returned instead? Anyway, I will have a
look at the code and see what presents itself (and if anyone else gets
there first, feel free to jump in!).
>
> Josef
>
> PS: It would be perfect if KCachegrind generally would get more useful
> for diverse tasks.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|