|
From: Harris, J. <Je...@ai...> - 2006-09-12 13:42:03
Attachments:
ppc-output.txt
x86-output.txt
|
I am trying to use Callgrind to profile our code running on our PPC 860
embedded platform. I have successfully cross-compiled Valgrind 3.2.0
and am able to run the utility. The results of the profiler are
different and not as useful as the results when I run the same
application on our x86 embedded platform. Both platforms use gcc 3.2.3
and glibc 2.3.6 with Linux 2.4.21-pre4. Valgrind was cross-compiled for
both platforms.
My simple test application is:
#include <iostream>
using namespace std;
int foo()
{
return 35;
}
int main()
{
cout << foo() << endl;
return 0;
}
When compiled with the cross C++ compiler with -g and -O0, the output on
PowerPC does not pick up the symbols for libstdc++. All I get in
kcachegrind are addresses. On the x86 platform, I get the symbols.
Also on the PPC run I get cycles detected in some of the dynamic loader
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.
In profiling our real application on ppc, the output in kcachegrind
seems to be getting the wrong symbols in some cases. The application
uses static and dynamic loading of shared libraries, but the app should
not dlclose any of the dynamic shared libraries it loaded. I have not
had time to create a smaller test case yet which would reproduce the
problem.
Are there known symbol resolution issues with the PowerPC port? I
couldn't find any mention in the FAQ or bug reports.
Also, in order to make Valgrind work for our PPC chip, I had to modify
Valgrind to accept 16 byte cache lines. There were several asserts in
the code for 32 or 128 bit sizes. I simply added in another condition
for 16 to work past the asserts. I'm not sure if additional changes are
needed, though.
Thanks,
Jeff
|
|
From: Tom H. <to...@co...> - 2006-09-12 13:54:48
|
In message <C01...@ai...>
Jeff Harris <Je...@ai...> wrote:
> When compiled with the cross C++ compiler with -g and -O0, the output on
> PowerPC does not pick up the symbols for libstdc++. All I get in
> kcachegrind are addresses. On the x86 platform, I get the symbols.
> Also on the PPC run I get cycles detected in some of the dynamic loader
> 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.
Have you checked what symbols were left in when you build libstdc++
for that machine? Are all libstdc+++ symbols missing? Or just some?
One obviously difference is that the x86 environment is using a
dynamic libstdc++ while the PPC environment appears to be using a
statically linked one.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2006-09-12 22:24:16
|
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 > 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. > > 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. 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 |