|
From: Oliver D. <od...@pa...> - 2007-02-13 14:38:04
|
Hi, I am trying to use callgrind to improve C++ software which is cross compiled for a ppc platform. When running valgrind --tool=callgrind on my testplatform, all symbols from the main file are missing so I only get addresses. On my host system everything is fine I find my methods in the output. ppc: fn=(5930) i686: fn=(5930) Request::Request(std::string const&, std::string const&, std::string const&, std::istream&) Seems like the ppc version cannot find the debug information. I am using valgrind version 3.2.3 and ppc_82xx-g++ version 3.2.2 (from eldk-3.0) for my targe platform and valgrind 3.2.3 and g++ 4.0.4 on my host platform. Did I overlook something? Do I have to use gcc 4 for my target platform? Oliver |
|
From: Josef W. <Jos...@gm...> - 2007-02-13 15:46:16
|
On Tuesday 13 February 2007, Oliver Dawid wrote: > Hi, > > I am trying to use callgrind to improve C++ software which is cross compiled for a ppc platform. When running valgrind > --tool=callgrind on my testplatform, all symbols from the main file are missing so I only get addresses. On my host system > everything is fine I find my methods in the output. > > ppc: > fn=(5930) > > i686: > fn=(5930) Request::Request(std::string const&, std::string const&, > std::string const&, std::istream&) This "(5930)" has nothing to do with any address, but is part of a compression scheme for callgrind.out files. It references the symbol no. 5930; at first occurence, this includes the symbol name, on further occurences the symbol name is left out. So: (1) Symbol 9530 can reference different symbols at every invocation of callgrind, even with the same program, but more so on different architectures; however, this is a pure file-internal mapping to get shorter files (especially for C++); you can switch it off with "--compress-strings=no". (2) The missing symbol name next to (5930) only means that the mapping of the number to the name already appeared earlier in the file, perhaps in a line "cfn=(5930) random_symbol". Can you do a "grep \(5930\) callgrind.out" to check this? If there in fact is no line which installs a symbol mapping for 5930, this would be a bug in writing the output, but does not mean anything regarding to missing debug info. Josef > Seems like the ppc version cannot find the debug information. > > I am using valgrind version 3.2.3 and ppc_82xx-g++ version 3.2.2 (from eldk-3.0) for my targe platform and valgrind 3.2.3 and g++ > 4.0.4 on my host platform. > > Did I overlook something? Do I have to use gcc 4 for my target platform? > > Oliver > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Oliver D. <od...@pa...> - 2007-02-14 16:18:04
|
(repost - did not send posting to the list) Hi Josef, Josef Weidendorfer wrote: > On Tuesday 13 February 2007, Oliver Dawid wrote: >> Hi, >> >> I am trying to use callgrind to improve C++ software which is cross compiled for a ppc platform. When running valgrind >> --tool=callgrind on my testplatform, all symbols from the main file are missing so I only get addresses. On my host system >> everything is fine I find my methods in the output. >> >> ppc: >> fn=(5930) >> >> i686: >> fn=(5930) Request::Request(std::string const&, std::string const&, >> std::string const&, std::istream&) > > This "(5930)" has nothing to do with any address, but is part of a > compression scheme for callgrind.out files. It references the symbol > no. 5930; at first occurence, this includes the symbol name, on > further occurences the symbol name is left out. Ok. > So: > > (1) Symbol 9530 can reference different symbols at every invocation > of callgrind, even with the same program, but more so on different > architectures; however, this is a pure file-internal mapping to > get shorter files (especially for C++); you can switch it off > with "--compress-strings=no". > > (2) The missing symbol name next to (5930) only means that the > mapping of the number to the name already appeared earlier in the > file, perhaps in a line "cfn=(5930) random_symbol". Can you do > a "grep \(5930\) callgrind.out" to check this? If there in fact > is no line which installs a symbol mapping for 5930, this would be > a bug in writing the output, but does not mean anything regarding > to missing debug info. Ok, got that. Here is the output. It was defined earlier in the file: cfn=(5930) boost::detail::shared_count::shared_count<char*, boost::checked_array_deleter<char> >(char*, boost::checked_array_deleter<char>) fn=(5930) But this wasn't the problem I have. I get tons of addresses instead of symbols as I expected: cfn=(7880) 0x00045EFC cfn=(3574) 0x000194D8 cfn=(3584) 0x000195FC cfn=(3754) 0x000419A0 cfn=(3914) 0x0002C2C4 cfn=(4002) 0x00022280 cfn=(7662) 0x0001CC70 cfn=(7802) 0x0002A4F4 cfn=(7868) 0x00040A80 cfn=(7936) 0x0004B7F8 While reference numbers are not comparable to my i686 output, I can only guess, that these symbols belong to code from my main binary. When I load that callgrind.out file into Kcachegrind I get binary object: unknown. Other methods/ functions from libc or ld are displayed with their symbol names (although there are functions, which also only have an address like above). I tried several debugging and profiling options for the gcc without change. When I use nm or objdump, I can see these symbols, so my binary definitely contains debug symbols. This seems to be a more common problem not only for callgrind. When running a memcheck I get stacks looking like this: ==917== Invalid read of size 4 ==917== at 0x10005C04: ??? ==917== by 0x100080E0: ??? ==917== by 0x1000854C: ??? ==917== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) ==917== Address 0x4026F44 is 4 bytes inside a block of size 32 free'd ==917== at 0xFFBBEC4: operator delete(void*) (vg_replace_malloc.c:244) ==917== by 0x10005B84: ??? ==917== by 0x10008090: ??? ==917== by 0x1000854C: ??? ==917== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) Any idea? |
|
From: Josef W. <Jos...@gm...> - 2007-02-14 18:57:40
|
On Wednesday 14 February 2007, Oliver Dawid wrote: > But this wasn't the problem I have. I get tons of addresses instead of > symbols as I expected: > > cfn=(7880) 0x00045EFC > cfn=(3574) 0x000194D8 > cfn=(3584) 0x000195FC > cfn=(3754) 0x000419A0 > cfn=(3914) 0x0002C2C4 > cfn=(4002) 0x00022280 > cfn=(7662) 0x0001CC70 > cfn=(7802) 0x0002A4F4 > cfn=(7868) 0x00040A80 > cfn=(7936) 0x0004B7F8 > > While reference numbers are not comparable to my i686 output, I can only > guess, that these symbols belong to code from my main > binary. When I load that callgrind.out file into Kcachegrind I get binary > object: unknown. Actually, no idea about that. For sure, if the addresses are inside of a mapping of your application code (or a shared library), VG should know about it. Can you check whether /proc/<pid>/maps for the mappings used for these addresses, while VG is running your code? If they are inside of anonymous memory ranges, VG can not be able to name them. This would be the case with code generated on the fly. > Other methods/ functions from libc or ld > are displayed with their symbol names (although there are functions, which also only have an address like above). > > I tried several debugging and profiling options for the gcc without change. > > When I use nm or objdump, I can see these symbols, so my binary definitely > contains debug symbols. Ah. You know which functions _should_ be called, and get the addresses above instead? Perhaps this is some trampoline code generated on the fly which calls the real functions instead? I ask because if KCachegrind talks about "unknown object", the addresses actually are absolute. So I do not see how you could search for these addresses in any binary, as you do not know the offset where it is mapped at run time. However, when callgrind knows about the binary, the address is a relative offset into the code segment, which can be used with nm/objdump. > This seems to be a more common problem not only for callgrind. When running a memcheck I get stacks looking like this: > > ==917== Invalid read of size 4 > ==917== at 0x10005C04: ??? > ==917== by 0x100080E0: ??? > ==917== by 0x1000854C: ??? > ==917== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) > ==917== Address 0x4026F44 is 4 bytes inside a block of size 32 free'd > ==917== at 0xFFBBEC4: operator delete(void*) (vg_replace_malloc.c:244) > ==917== by 0x10005B84: ??? > ==917== by 0x10008090: ??? > ==917== by 0x1000854C: ??? > ==917== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) Interesting. However, the addresses here are totally different from the ones above. > Any idea? Sorry, not really. Josef PS: You should know that call graph generation currently is kind of experimental with PPC. |
|
From: Oliver D. <od...@pa...> - 2007-02-15 08:42:11
|
Hi, Josef Weidendorfer wrote: > Actually, no idea about that. For sure, if the addresses are inside of > a mapping of your application code (or a shared library), VG should know > about it. Can you check whether /proc/<pid>/maps for the mappings used for > these addresses, while VG is running your code? > If they are inside of anonymous memory ranges, VG can not be able to name > them. This would be the case with code generated on the fly. I ran my program an saved maps file. Here are the results: valgrind --tool=memcheck produced the following: ---snip--- ... ==874== Invalid read of size 4 ==874== at 0x10009D38: ??? ==874== by 0x10008EC0: ??? ==874== by 0x10005C44: ??? ==874== by 0x10008108: ??? ==874== by 0x100087E4: ??? ==874== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) ==874== Address 0x402DFAC is 12 bytes inside a block of size 32 free'd ==874== at 0xFFBBEC4: operator delete(void*) (in /opt/nfs/usr/lib/valgrind/ppc32-linux/vgpreload_memcheck.so) ==874== by 0x10005BAC: ??? ==874== by 0x100080B8: ??? ==874== by 0x100087E4: ??? ==874== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) ==874== ... ---snip--- The maps file contains this: ---snip--- ... 10000000-10014000 rwxp 00000000 00:09 2839186 /opt/nfs/usr/bin/mmscript 10023000-10026000 rwxp 00013000 00:09 2839186 /opt/nfs/usr/bin/mmscript ... ---snip--- Obviously the addresses from valgrinds output are located in my binary which contains symbols. From objdump -t --demangle I get e.g.: ---snip--- ... 10007dec g F .text 0000044c parseInput(std::basic_istream<char, std::char_traints<char> >&) ... ---snip--- Which is the function where this error above occurs. 0x100080B8 is inside the function above (parseInput). 0x100087E4 is inside main: ---snip--- ... 10008518 g F .text 0000037c main ... ---snip--- I did not look into valgrind code (and I doubt it makes any sense) but there seems to be a problem in symbol lookup part. Oliver PS: I did also a callgrind run and found corresponding entries in output file: cfn=(5070) 0x10007DEC cfn=(4810) 0x1000852C cfn=(6328) 0x10005BDC cfn=(6336) 0x10008E70 and so on. |
|
From: Josef W. <Jos...@gm...> - 2007-02-15 14:33:31
|
On Thursday 15 February 2007, Oliver Dawid wrote: > ---snip--- > ... > ==874== Invalid read of size 4 > ==874== at 0x10009D38: ??? > ==874== by 0x10008EC0: ??? > ==874== by 0x10005C44: ??? > ==874== by 0x10008108: ??? > ==874== by 0x100087E4: ??? > ==874== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) > ==874== Address 0x402DFAC is 12 bytes inside a block of size 32 free'd > ==874== at 0xFFBBEC4: operator delete(void*) (in /opt/nfs/usr/lib/valgrind/ppc32-linux/vgpreload_memcheck.so) > ==874== by 0x10005BAC: ??? > ==874== by 0x100080B8: ??? > ==874== by 0x100087E4: ??? > ==874== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) > ==874== > ... > ---snip--- > > The maps file contains this: > ---snip--- > ... > 10000000-10014000 rwxp 00000000 00:09 2839186 /opt/nfs/usr/bin/mmscript > 10023000-10026000 rwxp 00013000 00:09 2839186 /opt/nfs/usr/bin/mmscript OK, that definitly seems to be a shortcoming in symbol reading in valgrind. Can you please raise a bug report with above information to not forget about this issue? Thanks, Josef |
|
From: Oliver D. <od...@pa...> - 2007-02-20 07:40:28
|
Hi, Josef Weidendorfer wrote: > On Thursday 15 February 2007, Oliver Dawid wrote: >> ---snip--- >> ... >> ==874== Invalid read of size 4 >> ==874== at 0x10009D38: ??? >> ==874== by 0x10008EC0: ??? >> ==874== by 0x10005C44: ??? >> ==874== by 0x10008108: ??? >> ==874== by 0x100087E4: ??? >> ==874== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) >> ==874== Address 0x402DFAC is 12 bytes inside a block of size 32 free'd >> ==874== at 0xFFBBEC4: operator delete(void*) (in /opt/nfs/usr/lib/valgrind/ppc32-linux/vgpreload_memcheck.so) >> ==874== by 0x10005BAC: ??? >> ==874== by 0x100080B8: ??? >> ==874== by 0x100087E4: ??? >> ==874== by 0xFA2DF68: (below main) (in /lib/libc-2.3.1.so) >> ==874== >> ... >> ---snip--- >> >> The maps file contains this: >> ---snip--- >> ... >> 10000000-10014000 rwxp 00000000 00:09 2839186 /opt/nfs/usr/bin/mmscript >> 10023000-10026000 rwxp 00013000 00:09 2839186 /opt/nfs/usr/bin/mmscript > > OK, that definitly seems to be a shortcoming in symbol reading in valgrind. > Can you please raise a bug report with above information to not forget > about this issue? OK did that. Its Bug 141744: "Symbol resolve problem on PPC MPC82xx platform with C++" I found out that it has something to do with virtual classes. When using simple code, everything is fine but using virtual classes, I get this resolve problem. Seems like the additional indirection confuses valgrind. Is there a quick solution? What can I do to get this running? Oliver |