Re: Ltdl and gcov
On Thu, Jul 30, 2009 at 5:06 AM, Bob Friesenhahnbfrie...@simple.dallas.tx.us wrote: On Wed, 29 Jul 2009, Ralf Wildenhues wrote: My guess would be that coverage support is not suited for unloading plugins. Â Maybe you can get more information about this on the gcc-help mailing list. It seems likely that the counters for the functions and arcs are allocated within the instrumented object files. Â Unloading the object files before the counters have been retrieved leads to the crash. For some reason, I couldn't reproduce the problem. It probably was a problem on my side. Sorry for the noise, -- Thomas Moulard ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Ltdl and gcov
Hello Thomas, * Thomas Moulard wrote on Mon, Jul 27, 2009 at 11:43:24AM CEST: I am trying to integrate gcov into my buildchain but I ran into the following problem: if I compile my Autoconf/Automake/Libtool package using -fprofile-arcs and -ftest-coverage, the program produces a segv at the end of the execution. This program load a ltdl plug-in, do a simple thing and unload it. The problem only arrive when I compile with -fprofile-arcs, -ftest-coverage and if lt_dlclose is called to properly unload the plug-in. If I do not call lt_dlclose it always works, if I do not use these two compiling flags it always work and Valgrind does not report any error. When it fails, gdb and valgrind indicates that the program jumped to an invalid address in libc-start.c:252. Last thing: when I tried to compile with test coverage support both my plug-in /and/ my loader were recompiled with that flag. This sounds very much like a bug in libc, GCC coverage support, or the interaction between the two. If you can reproduce the issue while using dlopen and dlclose directly (thus by-passing libltdl), then you have proof that libltdl is not part of this issue. My guess would be that coverage support is not suited for unloading plugins. Maybe you can get more information about this on the gcc-help mailing list. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Ltdl and gcov
On Wed, 29 Jul 2009, Ralf Wildenhues wrote: My guess would be that coverage support is not suited for unloading plugins. Maybe you can get more information about this on the gcc-help mailing list. It seems likely that the counters for the functions and arcs are allocated within the instrumented object files. Unloading the object files before the counters have been retrieved leads to the crash. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Ltdl and gcov
Hello, I am trying to integrate gcov into my buildchain but I ran into the following problem: if I compile my Autoconf/Automake/Libtool package using -fprofile-arcs and -ftest-coverage, the program produces a segv at the end of the execution. This program load a ltdl plug-in, do a simple thing and unload it. The problem only arrive when I compile with -fprofile-arcs, -ftest-coverage and if lt_dlclose is called to properly unload the plug-in. If I do not call lt_dlclose it always works, if I do not use these two compiling flags it always work and Valgrind does not report any error. When it fails, gdb and valgrind indicates that the program jumped to an invalid address in libc-start.c:252. Last thing: when I tried to compile with test coverage support both my plug-in /and/ my loader were recompiled with that flag. For now, I workaround the problem by doing: # Make sure one does not compile a plug-in with test coverage support as # it seems to trigger a segv at exit. roboptim_core_dummy_plugin_la_CXXFLAGS = \ `echo $(CXXFLAGS) | sed -e 's/-ftest-coverage//' -e 's/-fprofile-arcs//'` ...but a clear explanation of this issue would be greatly appreciated. Thanks, -- Thomas Moulard ___ http://lists.gnu.org/mailman/listinfo/libtool
gcov
Hello all, I use libtool 1.5.22 in my project. I have the following directory structure: /dir/ /dir/build/ /dir/build/.libs/ /dir/build/.libs/a.o /dir/build/a.lo /dir/build/a.o /dir/prj/ /dir/prj/a/ /dir/prj/a/a.c When I call gcov under /dir/build, it says stamp mismatch with graph file (perhaps the *.gc* files do not match a.o?). So I call it from /dir/build/.libs. In this case, a.c is looked for in ../prj/a, which doesn't exist. So, I've ln -s ../prj /dir/build/prj. Then gcov works as expected. Is there a better way to do that? Thanks in advance, Baurzhan. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: gcov
Hello Baurzhan, * Baurzhan Ismagulov wrote on Fri, Sep 22, 2006 at 02:19:32PM CEST: /dir/ /dir/build/ /dir/build/.libs/ /dir/build/.libs/a.o /dir/prj/ /dir/prj/a/ /dir/prj/a/a.c When I call gcov under /dir/build, it says stamp mismatch with graph file (perhaps the *.gc* files do not match a.o?). So I call it from /dir/build/.libs. In this case, a.c is looked for in ../prj/a, which doesn't exist. So, I've ln -s ../prj /dir/build/prj. Then gcov works as expected. Is there a better way to do that? Does libtool --mode=execute gcov ... work? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: gcov
Hello Ralf, thanks much for your prompt answer! On Fri, Sep 22, 2006 at 02:59:15PM +0200, Ralf Wildenhues wrote: When I call gcov under /dir/build, it says stamp mismatch with graph file (perhaps the *.gc* files do not match a.o?). So I call it from /dir/build/.libs. In this case, a.c is looked for in ../prj/a, which doesn't exist. So, I've ln -s ../prj /dir/build/prj. Then gcov works as expected. Is there a better way to do that? Does libtool --mode=execute gcov ... Nope, stamp mismatch with graph file when called from /dir/build. With kind regards, Baurzhan. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: gcov
Hello Baurzhan, * Baurzhan Ismagulov wrote on Fri, Sep 22, 2006 at 03:28:09PM CEST: When I call gcov under /dir/build, it says stamp mismatch with graph file (perhaps the *.gc* files do not match a.o?). So I call it from /dir/build/.libs. In this case, a.c is looked for in ../prj/a, which doesn't exist. So, I've ln -s ../prj /dir/build/prj. Then gcov works as expected. Is there a better way to do that? libtool --mode=execute gcov ... Nope, stamp mismatch with graph file when called from /dir/build. Hmm, ok. Can you show a bit what you're doing? My small tests with libtool/tests/demo must be too simplistic to expose the issue fully. Meanwhile, I think there also is a simple workaround: if you configure with an absolute path: mkdir build cd build /absolute/path/to/source/tree/configure [...] make then you should be able to skip the symlinking step; but it seems you still have to go to the .libs subdirectory. Not yet sure how to go about a better solution. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
