|
From: Jason W. <jp...@im...> - 2005-04-18 03:51:30
|
I'm unaware of any kcachegrind list, so here goes... Anyone know how to get the kcachegrind source annotation window to work on shared libraries (g++ -shared) ? It all works on the primary executable, but our architecture is very heavily plugin-based (dlopen, dlsym). The call graph, callers, callees, etc all seem to show up fine, just not the visualizer "Source". kcachegrind says "no source available for" and "no debug information present" for the .so filename. I specified all the source directories explicitly in the 'Configure kcachgrind' GUI under (always). Is there a callgrind option or compiler option I'm missing beyond the -g2 I've got? Here's the .so link line, massaged to shorten it a little: ccache g++-3.4 -fPIC -shared -o <ours>.so -D_DEBUG -g2 -Wall -Winvalid-pch -DREENTRANT -DZT_POSIX -ftemplate-depth-60 -DBOOST_HAS_THREADS -I/usr/X11R6/include -I<ours> <many of ours>.o -ldl -L<ours> -l<several of ours> -lpthread -lrt -lboost_filesystem -lboost_regex -lboost_thread -lm -lc -lcrypt -ldl -- _ ( \ _ \ /_ / _ _ Jason Weber Glendale, CA \|(\/)())) \/\/(-/_)(-/( http://www.imonk.com/baboon ba...@im... // we...@ac... (/ |
|
From: Jason W. <jp...@im...> - 2005-04-18 05:56:16
|
More info: In the callgrind.out file, if I understand the format correctly, the line numbers in .so related source files are zero: fl=(247) Habitat.cc fn=(7802) _GLOBAL__I__ZN2fe7Habitat7setTimeEf 0 14 0 8 4 0 0 4 fi=(237) cfn=(7804) __static_initialization_and_destruction_0(int, int) calls=2 0 0 812 278 128 58 0 1 52 0 1 0 6 4 fn=(7804) 0 28 4 8 6 0 0 6 fi=(237) 0 2 2 cob=(7) cfi=(52) cfn=(3680) calls=2 0 0 58 22 18 fe=(247) 0 16 2 8 2 0 0 2 fi=(237) 0 2 2 0 2 cob=(3) cfi=(24) cfn=(2924) calls=2 30 0 516 136 94 6 0 1 2 0 1 fe=(247) 0 190 110 0 42 0 0 42 fn=(24288) fe::Habitat::calcForces(float, fe::Vector<4, float>, fe::Vector<4, float>) 0 546 130 260 56 2 0 6 2 fi=(237) 0 26 26 0 26 2 0 1 1 cob=(12) cfi=(433) cfn=(24124) calls=26 49 0 884 494 338 4 [...] -- _ ( \ _ \ /_ / _ _ Jason Weber Glendale, CA \|(\/)())) \/\/(-/_)(-/( http://www.imonk.com/baboon ba...@im... // we...@ac... (/ On Sun, Apr 17, 2005 at 08:49:58PM -0700, Jason Weber wrote: > I'm unaware of any kcachegrind list, so here goes... > > Anyone know how to get the kcachegrind source annotation window > to work on shared libraries (g++ -shared) ? > > It all works on the primary executable, but our architecture is > very heavily plugin-based (dlopen, dlsym). > > The call graph, callers, callees, etc all seem to show up fine, > just not the visualizer "Source". > > kcachegrind says "no source available for" and "no debug information present" > for the .so filename. I specified all the source directories explicitly > in the 'Configure kcachgrind' GUI under (always). > > Is there a callgrind option or compiler option I'm missing > beyond the -g2 I've got? > > Here's the .so link line, massaged to shorten it a little: > > ccache g++-3.4 -fPIC -shared > -o <ours>.so > -D_DEBUG -g2 -Wall -Winvalid-pch -DREENTRANT -DZT_POSIX > -ftemplate-depth-60 -DBOOST_HAS_THREADS > -I/usr/X11R6/include -I<ours> > <many of ours>.o > -ldl -L<ours> > -l<several of ours> > -lpthread -lrt -lboost_filesystem -lboost_regex -lboost_thread > -lm -lc -lcrypt -ldl > > -- > _ > ( \ _ \ /_ / _ _ Jason Weber Glendale, CA > \|(\/)())) \/\/(-/_)(-/( http://www.imonk.com/baboon ba...@im... > // we...@ac... > (/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Igmar P. <mai...@jd...> - 2005-04-18 07:13:25
|
<snip> > It all works on the primary executable, but our architecture is > very heavily plugin-based (dlopen, dlsym). <snip> > kcachegrind says "no source available for" and "no debug information present" > for the .so filename. I specified all the source directories explicitly > in the 'Configure kcachgrind' GUI under (always). Don't do a dlclose() on the plugins, as that will remove them from address space, and prevents VG from doing lookups. Usually this can be easely done using #ifdef's, or with the VG runtime macros. Regards, Igmar |
|
From: Jason W. <jp...@im...> - 2005-04-18 09:50:26
|
That didn't help, but I was able to get them to show up by explicitly adding every plugin that might possibly get loaded to the main executable's link line (then they're not exactly acting as extensability plugins, though). -- _ ( \ _ \ /_ / _ _ Jason Weber Glendale, CA \|(\/)())) \/\/(-/_)(-/( http://www.imonk.com/baboon ba...@im... // we...@ac... (/ On Mon, Apr 18, 2005 at 09:15:14AM +0200, Igmar Palsenberg wrote: > > <snip> > > > It all works on the primary executable, but our architecture is > > very heavily plugin-based (dlopen, dlsym). > > <snip> > > > kcachegrind says "no source available for" and "no debug information present" > > for the .so filename. I specified all the source directories explicitly > > in the 'Configure kcachgrind' GUI under (always). > > Don't do a dlclose() on the plugins, as that will remove them from address > space, and prevents VG from doing lookups. Usually this can be easely done > using #ifdef's, or with the VG runtime macros. > > > Regards, > > > Igmar > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Josef W. <Jos...@gm...> - 2005-04-19 08:12:05
|
On Monday 18 April 2005 09:15, Igmar Palsenberg wrote: > > kcachegrind says "no source available for" and "no debug information > > present" for the .so filename. I specified all the source directories > > explicitly in the 'Configure kcachgrind' GUI under (always). > > Don't do a dlclose() on the plugins, as that will remove them from address > space, and prevents VG from doing lookups. Usually this can be easely done > using #ifdef's, or with the VG runtime macros. BTW, this hint is wrong/unneeded with callgrind. The first time a code is executed, it is inserted into hashes using some debug info as keys (function name, ELF object, source file). A dlclose() will keep the collected info, indexed via these names. Even if the same plugin is dlopen'ed again later at a different load address, it will correctly add up profile data. Josef > > > Regards, > > > Igmar > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Josef W. <Jos...@gm...> - 2005-04-18 09:52:14
|
Hi Jason, On Monday 18 April 2005 05:49, Jason Weber wrote: > I'm unaware of any kcachegrind list, so here goes... That is actually a good idea. I'll see if I can setup some line on sourceforge... > It all works on the primary executable, but our architecture is > very heavily plugin-based (dlopen, dlsym). That should be no problem. > The call graph, callers, callees, etc all seem to show up fine, > just not the visualizer "Source". > > kcachegrind says "no source available for" and "no debug information > present" for the .so filename. On Monday 18 April 2005 07:54, Jason Weber wrote: > In the callgrind.out file, if I understand the format correctly, > the line numbers in .so related source files are zero: > > fl=(247) Habitat.cc > fn=(7802) _GLOBAL__I__ZN2fe7Habitat7setTimeEf > 0 14 0 8 4 0 0 4 This is the problem. Either the compiler generates bad debug info, or it generates debug info in a format which Valgrind can not parse. > Here's the .so link line, massaged to shorten it a little: The link line is not important. You have to specify -g when compiling the object files. > ccache g++-3.4 -fPIC -shared Usually, Valgrind can parse debug info from GCC 3.4 quite fine. Sorry, no further ideas. Josef |