Re: [Valgrind-users] identifying conditionals during execution

[<and...@gm...>]

With John's help I have been able to identify all the jumps in an
application and counting them. But I get way more jumps than I really
expected (see below) and I am curious where they come from. Is there
any documentation on where all (>200,000) the jumps come from? Is
there any documentation on how I can differ these jumps from each
other so that I can only look at the ones I am interested in?

The application I am instrumenting is:

int main(){
    int x =2;
    if(x==2){
    }
};

And the output I get is:
==17918== Jumps direct
==17918==   counted:         145,795 ( 38%)
==17918== Jumps indirect
==17918==   counted:         2,994 (  0%)
==17918== Calls direct
==17918==   counted:         13,341 (  3%)
==17918== Calls indirect
==17918==   counted:         228 (  0%)
==17918== Returns
==17918==   counted:         13,629 (  3%)
==17918== Conditionals
==17918==   counted:         202,644 ( 53%)
==17918== Other
==17918==   counted:         52 (  0%)

Andreas


On 4/20/07, Josef Weidendorfer <Jos...@gm...> wrote:
> On Friday 20 April 2007, John van Schie wrote:
> > Nicholas Nethercote wrote:
> > >
> > > It can.  You'll probably have to write a new tool, though.  The "Lackey"
> > > tool (in lackey/lk_main.c) does some counting of branches with its
> > > --basic-counts option.
> > >
> > > Nick
> >
> > To add to this, as a matter of fact, I've recently created a tool that
> > counts the direct/indrect branches, direct/indirect calls, conditional
> > jumps and returns. Maybe this is a good starting point for you to begin
> > with Andreas. Please let me know if you are interested.
>
> Callgrind also collects (conditional) jumps when you pass the
> "--collect-jumps=yes" (in addition to "--dump-instr=yes") option.
> KCachegrind can show this jump info in the assembler view
> (see e.g. screenshot attached).
> However, jump annotation in the source view currently is confusing,
> as jumps between source lines because of instruction reordering
> are not shown.
>
> Another note: With PPC, there are not really call and return isntructions.
> Callgrind has some (currently quite bad) heuristic to see what jump
> can be interpreted as a call/ret; in this szenario, you also get conditional
> calls and conditional returns, which do not exist with x86 and are not handled
> correctly by callgrind :-(
>
> I get the feeling that there are a lot of useful tools "out in the wild",
> and everybody would profit if we chould collect these even in an
> experimental stage, as already was discussed some time ago.
>
> Josef
>
>