Re: [Valgrind-users] Callgrind results on ppc

[Harris, J. <Je...@ai...>]

I think I have a simple program created to highlight the differences
between the x86 and ppc output of callgrind and seen in kcachegrind.
The program is pretty basic:

#include <iostream>
#include <string>
using namespace std;
int foo()
{
    return 35;
}
int main()
{
    cout << foo() << endl;
    return 0;
}

The call to foo appears the same in both attached outputs of running
valgrind with callgrind.  The differences show when the ppc program
calls the libstdc++ methods for operator<<().  If you look at the output
for x86, kcachegrind shows main calling foo, two libstdc++ methods, and
_dl_runtime_resolve (presumably to find and relocate the libstdc++
methods).

On ppc, the same call to main shows a call to foo and exit, but shows
one call to 0x10000E2C.  Address 0x10000E2C is the location of the
dynamic relocation record for the operator<< method.  Stepping into
0x10000E2C, I see the call to the operator<< method as in the x86.  But,
I have to step further into the operator<< call to see another call to a
dynamic relocation record in order to see the second libstdc++ method as
in x86.  In the disassembly of main, both libstdc++ calls occur in main,
there is no recursion.

I'm guessing that valgrind/callgrind is not seeing a "return" from the
dynamic relocation record, causing it to think the function never exits.
Does valgrind/callgrind perhaps not recognize that 0x10000E2C is a
relocation entry which may act differently than a local function call?

Both the ppc and x86 were built with the same version of gcc and
libstdc++.  They were compiled with -g and -O0 flags.

Thanks,
Jeff

-----Original Message-----
From: Josef Weidendorfer [mailto:Jos...@gm...]=20
Sent: Tuesday, September 12, 2006 6:24 PM
To: val...@li...
Cc: Harris, Jeff
Subject: Re: [Valgrind-users] Callgrind results on ppc


Hi,

On Tuesday 12 September 2006 15:41, Harris, Jeff wrote:
> Also on the PPC run I get cycles detected

See below.

> in some of the dynamic loader=20
> function calls, like dl_main.  The cycles do not appear on the x86
run.
> I have attached the output from Valgrind for both the ppc and x86
runs.
>=20
> In profiling our real application on ppc, the output in kcachegrind
> seems to be getting the wrong symbols in some cases.

Hmm... either there is some bug in Valgrind (wrong interpretation of
symbol information on PPC?), or the compiler does not produce correct
data (e.g. wrong "length" of symbols?).
If some code gets the wrong function name attributed, it easily can be
that
KCachegrind detects some bogus cycles.=20

In general some warning about callgrind on PPC32/64. Obviously, it is
reasonable stable, but I never had time to fully check whether call
graph tracing on PPC produces senseable call graphs in all cases.
At least, one problem is known to not be handled correctly:
On PPC, jumps are used for both calls and returns. So theoretically,
there are conditional calls and returns on PPC. This is not
possible on x86, and currently _not_ handled in callgrind. However,
conditional calls/returns seem to be used only in rare cases (?).

Josef