|
From: Benjamin M. <be...@me...> - 2007-08-28 22:51:31
|
>> From the spec it would seem that the jump is
>> assigned to ~QColumnView (is that right?),
>
> Yes.
Excellent, that I what I thought, but wasn't sure because it didn't
appear in KCachegrind
>> but if I load it up in
>> KCachegrind I don't see any jumps.
>
> I assume you talk about the jump annotation in the source view
> (as your dump data is only about line numbers as far as I see).
> In this case, arrows/jumps are suppressed in some situations.
> If you look at these lines:
>
> * 24
> jcnd=8/8 *
> *
>
> The conditional jump source is a instruction associated to a
> given source line X by the debug information generated by the
> compiler.
> The jump target is the same line X.
>
> In general, jump annotations are suppressed by KCachegrind if they
> are from a line to the same or the next line. I had some reason for
> this, but I am not sure any more. But yes, it should be noted in the
> documentation.
Yah it is understandable that you would want to hide many of the
jumps in the GUI as they are not what the user it looking for.
> You will see the jump in the assembly view (with "--dump-instr=yes").
>
>> Lastly there are a few calls= that have negative numbers. Because
>> cfi and cfn are specified shouldn't the destination position be in
>> the line number in the file (such as when they are 454) or is the
>> line number of the jump relative to the current line number
>> (resulting in 0 both times)?
>
> Callgrind by default both uses "name" and "subposition" compression
> as they are called in the format spec. The latter means that line
> numbers (which count as "subposition" as well as instruction
> addresses)
> usually are relative. The spec states that a subposition starting
> with a "-" is a negative difference relative to the previous
> subposition.
> As absolute subpositions can not be negative, this is non-ambiguous.
What was confusing me was that I figured it would write "0" rather
then "-84" (because 0 is only one char vs three and more likely to
occur, leading to better compression)
> So yes, the line numbers of the call destination in your example
> are zero (ie. unknown/no debug info given).
> You could argue that this spec is a little bit counter-intuitive, as
> you get relative line numbers from different functions. What I am not
> sure about is why there are the source files specified in your example
> despite of the fact that line number information is missing; however,
> file (1) could very well be the "unknown" file.
Yup, 47 (earlier in the file, is unknown)
cfi=(47) ???
cfn=(4782) 0x00121917
> I suppose you want to parse this data?
How did you guess :)
> If you are unsure about the correctness, it is good to switch off
> the compression methods ("--compress-strings=no --compress-pos=no").
> This also is easier for parsing.
See my other e-mail where I made a tiny tool to decompress callgrind
files :)
> You can also have a look at the parser in KCachegrind.
Yah I skimmed through it and the annotate script. I wrote a very
small class that can be used to extract data from a callgrind file.
My use cases are
1) give me all the lines hit in file X
2) give me all the jumps in file X
(Sidenote: beyond that I am thinking of making a tiny command line
app to easily grab information out that can be used in all sort of
scripts. Such as:
- What files/functions/lines are used
- How expensive is obj/file/function x
- How many times is x called)
This class replaces the valgrind tool I wrote last week to acquire
coverage data. It is a much cleaner solution. Once it has the
information it is combined with the ast tree for the source I want to
get coverage on and it then generates a report. Below is the first
version of this report:
Function coverage - Has each function in the program been executed?
Functions: 6/6 100%
Statement coverage - Has each line of the source code been executed?
Executed: 83/87 95%
Condition coverage - Has each evaluation point (such as a true/false
decision) been executed?
Executed: 47/50 94%
Lines not touched:
167 [c] c: ulong self;
178 [j] f: if (!isLocked) {
180 [c] c: isLocked = d->wait();
181 [c] c: Q_ASSERT_X(isLocked, "QMutex::lock", "Internal
error, infinite wait has timed out.");
184 [c] c: d->contenders.deref();
199 [j] f: if (d->owner == self)
200 [c] c: qWarning("QMutex::lock: Deadlock detected in
thread %ld", d->owner);
227 [c] c: ulong self;
283 [c] c: ulong self;
345 [j] f: if (!d->contenders.testAndSetRelease(1, 0))
346 [c] c: d->wakeUp();
-Benjamin Meyer
|