https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
--- Comment #9 from Gejoe <gejoed at rediffmail dot com> ---
Hi team,
I'm here to say that the issue is sorted out now for me.
The gcda stamp mismatch would be seen when there is a recompilation of the
source file for any reason. In my project, there was a particular compilation
to create a reference object (say refo) as part of some thread safe related
code.
Consider a C file by name src-file.c , I found out that there was a specific
compilation (part of the thread safe related code) after the initial
compilation of the file. The specific latter compilation line would look like :
gcc <CFLAGS> -c src-file.c -o src-file.refo
This was not done for all source files but only for some components.
Now this refo file was generated all these years and with gcc versions
including 10.3.0. There was not any stamp mismatch issue for src-file.gcno and
src-file.gcda till 10.3.0. However with gcc 11.4.0, we could see the stamp
mismatch issue started appearing and it was narrowed down (using inotifywait
tool) to gcno file modification during the build process.
I found that there is nothing wrong with __gcov_dump() API usage or behaviour.
While running make (compilation of the source files and also the refo object
related compilation) the following script was used for run in parallel:
#!/bin/sh
inotifywait -mr --format '%e %w%f' <src-file directory path where make is
running> | while read event file ;
do
if [[ "$file" == *.gcno ]] ; then
echo "$file $event"
gcov-dump $file | grep stamp
fi
done
---------------------------------------------------------
The above shell script was run in another tab when make was running for the
component. The script run after sometime had to be killed as it was using while
loop and gcov-dump of the src-file.gcno would be leading access of the file and
thereby leading to recursion (of intoifywait). In the output of the script run,
I could see the stamp value was getting altered after a particular point and
then I narrowed that down to refo object related compilation line present in
the makefile.
Next question was why was that not happening so far(until gcc 11.4.0 was used).
It was found that with gcc 10.3.0 the refo object line compilarion as shown
above (ie. gcc <CFLAGS> -c src-file.c -o src-file.refo) resulted in creation
of src-file.refo.gcno file and src-file.gcno was not getting modified. With gcc
11.4.0, it was found that after the compilation, src-file.refo.gcno is not
getting created but src-file.gcno is getting modified/regenerated thereby
resulting in new gcno timestamp. The gcda time stamp will be the one
corresponding to the original src-file compilation and not to the one generated
after refo file generation.
Is this difference due to the changes in gcc11 series ? I could see -dumpbase
option coming in gcc11 which was not there earlier.
https://gcc.gnu.org/onlinedocs/gcc-11.4.0/gcc/Overall-Options.html#index-dumpbase
https://gcc.gnu.org/gcc-11/changes.html
Awaiting some reply from GCC/GCOV experts here.
Thanks to all for whatever support was given.
