|
From: John T. <joh...@bi...> - 2008-05-14 07:22:29
|
I'm trying to profile powerpc applications using valgrind on a powerpc system but can't seem to generate any symbolic information in the callgrind.out.xx file even though I have a full set of binutils installed on the target board. I get the full dump and the information "looks" correct but without symbolic information its of limited use. Not sure if this is connected but if I use Kcachegrind on an x86 box to view the data I get the following error even if I overwrite the x86 objdump with objdump from my cross compilation environment. Assembler There seems to be an error trying to execute the command objdump -C -d --start-address=0x10006E10 --stop-address=0x10175BA8 "" Check that the ELF object used in the command exists Check that you have installed 'objdump' This utility can be found in the 'binutils' package. Any hints/tips as to where valgrind looks for objdump or what else I could do to try and debug this. Cheers. |
|
From: Josef W. <Jos...@gm...> - 2008-05-15 17:47:13
|
Hi, a general note: The call graph building with PowerPC code still is experimental and there are issues with detecting calls/returns, so the call graph is (at least partial) wrong, including any inclusive costs. Better use just cachegrind for now. On Wednesday 14 May 2008, John Traill wrote: > I'm trying to profile powerpc applications using valgrind on a powerpc system > but can't seem to generate any symbolic information in the callgrind.out.xx > file even though I have a full set of binutils installed on the target board. > I get the full dump and the information "looks" correct but without symbolic > information its of limited use. Unfortunately I have no idea what's wrong here. Callgrind uses the generic Valgrind functionality to get symbols (ie. checking both the static and dynamic symbol table). > Not sure if this is connected but if I use Kcachegrind on an x86 box to view > the data I get the following error even if I overwrite the x86 objdump with > objdump from my cross compilation environment. > > Assembler > > There seems to be an error trying to execute the command > > objdump -C -d --start-address=0x10006E10 --stop-address=0x10175BA8 "" Yes, this seems to be related. The data file provides no file name for the ELF object where the code lies in. What is the output of "valgrind -v ..." on the powerpc system? Josef |
|
From: john t. <joh...@bi...> - 2008-05-16 14:14:35
|
I have the same problems with using the vanilla 3.3.0 release and several updates from svn. Version only reports "valgrind-3.4.0.SVN" with this build. Cheers Quoting Josef Weidendorfer <Jos...@gm...>: > Hi, > > a general note: > The call graph building with PowerPC code still is experimental and there > are issues with detecting calls/returns, so the call graph is (at least > partial) wrong, including any inclusive costs. Better use just cachegrind > for now. > > On Wednesday 14 May 2008, John Traill wrote: > > I'm trying to profile powerpc applications using valgrind on a powerpc > system > > but can't seem to generate any symbolic information in the callgrind.out.xx > > > file even though I have a full set of binutils installed on the target > board. > > I get the full dump and the information "looks" correct but without > symbolic > > information its of limited use. > > Unfortunately I have no idea what's wrong here. Callgrind uses the generic > Valgrind > functionality to get symbols (ie. checking both the static and dynamic > symbol > table). > > > Not sure if this is connected but if I use Kcachegrind on an x86 box to > view > > the data I get the following error even if I overwrite the x86 objdump with > > > objdump from my cross compilation environment. > > > > Assembler > > > > There seems to be an error trying to execute the command > > > > objdump -C -d --start-address=0x10006E10 --stop-address=0x10175BA8 "" > > Yes, this seems to be related. The data file provides no file name > for the ELF object where the code lies in. > > What is the output of "valgrind -v ..." on the powerpc system? > > Josef > > -- |