|
From: Bryan M. <om...@br...> - 2006-08-07 21:47:03
|
Hi Josef,
we should consider irc or skype to chat I think, apart from the lack of
record :(
Bryan
Josef Weidendorfer wrote:
> On Monday 07 August 2006 22:21, you wrote:
>> 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.
>
> I am not sure, that "not even compiled files" should influence the coverage.
> How do you want to detect them? Of course, debug info is not available for
> such files, and you would need to parse them yourself.
We would already have a list of source files in a directory. Flagging up
source files not in the list should be trivial. A separate "source file
with no executable lines" statistic or something as simple would do the
job. I just intended for it to draw attention to there being a source
file that isn't being used - the ultimate in 0 coverage...
>
>>> With "lineWithCode", the problem to show huge context should be gone.
>> A "show entire file" option might be a nice alternative?
>
> Hmm... yeah, I could put this option into the context menu for
> source annotation. The same for assembler annotation (show disassembler
> of full object) is probably not such a good idea...
indeed.
>
>>>> 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.
>
> Ah, I see. The 500 was a pure arbitrary limit, to keep the GUI snappy;
> some limit is needed because Qt3 creates for every list item an object,
> so huge lists are both time/space consuming (and running OpenOffice, you
> easily get 50000 functions). This will be moot with Qt4, as list items
> use the applications own model there, so huge lists do not add any
> overhead. However, with profiling, you usually are only interested in the
> top entries.
I thought it would be something like this (I have inexpertly used QT
before). For profiling, this is fine but for coverage, every file is
interesting and should be available.
>
>>>> 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.
>
> Yup.
>
>> 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
>
> Sure, some useful extension of the tool API is always welcome.
>
storage.c looks as though it would be the place for a new function.
Passing in a filename and returning the source line data shouldn't be
too difficult by the look of it.
>> 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)));
>
> Hmm, this looks already quite complicated. Why not an iterator function?
It looks a lot simpler with the sizeof(char) stripped out (assuming it
to be 1 can be dangerous sometimes):
bits[line_num / 8] |= (1 << (line_num & 7));
At some point, the information would probably need to be stored. I
remember reading that the debug information is lost when an object is
unloaded. If this is the case (I'm old - my memory can be a right thingy
at times) then the read would have to happen mid run and the information
be cached until the end when it can be output. This is unless the file
format for kcachegrind is happy to have intermingled files and function
information in which case, it could be output immediately and an
iterator might be fast enough. The key thing for me is to minimise the
impact to the program under test thus allowing a greater range of
programs to use it.
>
> Josef
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|