|
From: Philippe W. <phi...@sk...> - 2011-11-09 22:23:05
|
I am busy setting up the nightly run on ppc64/f16.
Doing that, encountered quite some failed tests : a few crashes, a few debug info reading failure, ...
Bref, business as usual :).
Except one very puzzling failure for badfree3.vgtest : the source file output
in the stack trace was an absolute filename in an unrelated valgrind build.
After searching a little bit (I mean: more than 2 hours :), it looks like on f16
(or at least on the f16 installation on gcc110 farm system),
a "caching compiler" is "on top of gcc" and does not invoke gcc if it finds
that a similar file was already compiled and the result is in a cache directory
and ccache can prove it will give the same code (I guess using various checksums on
the pre-processed sources or similar).
One paragraph of this ccache doc (found on the net) tells:
'If you specify an absolute path to the source code file and compile with -g, the source code path
stored in the object file may point to the wrong directory, which may prevent debuggers like GDB
from finding the source code. Sometimes, a work-around is to change the directory explicitly
with the "cd" command in GDB."'
Well, it seems the Valgrind stack trace also finds this "other absolute source file".
In other words, the behaviour I am observing is:
if you compile a Valgrind in a directory X
and then you compile a Valgrind in a directory Y
and ccache can determine that the compilation result for some source files of Y will be the same as
the cached results of X, then it will rather re-use the .o cached from the Valgrind X to link the Valgrind Y.
Currently only observed with the badfree regression test executable, and only visible in the badfree3.vgtest
(as this test uses the option --fullpath-after=${PWD} to filter a part of the absolute pathname.
But as the full pathname recuperated starts with another directory than PWD, nothing is filtered,
and the test fails. I guess we can have many other .o recuperated from another ("unrelated") build.
Sounds like it would be better to disable this caching compiler for Valgrind builds ?
Or does someone master better this ccache thingy so as to make it work better for Valgrind
and not have "random" failure or un-debuggability depending on what you compiled
some time before and then removed ?
Philippe
|