[Bug gcov-profile/114751] .gcda:stamp mismatch with notes file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 --- Comment #9 from Gejoe --- 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 -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' | 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 -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.
[Bug gcov-profile/114751] .gcda:stamp mismatch with notes file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 --- Comment #7 from Gejoe --- (In reply to Richard Biener from comment #6) > I have no idea why the values differ but I suspect the copying since we seem > to use the file modification time at some point. As a workaround I would > suggest > to binary-patch one of the file to make the stamp match the other ... We do use __gcov_dump() in the program execution to get all the gcda files, tar them up to a file name and we move that to the workspace where build was done we use a script to run gcov so that gcov files are created finally. So, will there be any changes in GCC 11.x (compared to 10.3.0) where __gcov_dump and the ensuing copy process need to be taken care in a better way ? I'm not sure of the binary-patching of the file mentioned above. Can you elaborate that suggestion ? Thank you for bearing with my queries patiently and for the possible help given.
[Bug gcov-profile/114820] Gcov 11.4.0 .gcda:stamp mismatch with notes file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114820 --- Comment #2 from Gejoe --- (In reply to Andrew Pinski from comment #1) > . > > *** This bug has been marked as a duplicate of bug 114751 *** OK, looks like that bug is not being looked at for further replies. Let me know if any info is sought for. Thanks.
[Bug gcov-profile/114751] .gcda:stamp mismatch with notes file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 --- Comment #5 from Gejoe --- (In reply to Gejoe from comment #2) > For me, it is like this (just keeping the sample filenames as such but the > values are real ones shown while checking with gcov-dump) : > > $gcov-dump ./obj-dir-path/src-file.gcda > ./obj-dir-path/src-file.gcda:data:magic `gcda':version `B14*' > ./obj-dir-path/src-file.gcda:stamp 2912455990 > : > > > $ gcov-dump ./obj-dir-path/src-file.gcno > ./obj-dir-path/src-file.gcno:note:magic `gcno':version `B14*' > ./obj-dir-path/src-file.gcno:stamp 2912494680 > : > > > Does this indicate something more to be checked ? > > In the previous branch where gcc 10.3.0 is used, I could see same stamp > value for the gcov-dump of same gcda and gcno files there - 3176078538. > > Awaiting reply. > > Thanks. Hi team, Can I expect any reply on my message posted above ? Thanks, Gejoe
[Bug gcov-profile/114820] New: Gcov 11.4.0 .gcda:stamp mismatch with notes file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114820 Bug ID: 114820 Summary: Gcov 11.4.0 .gcda:stamp mismatch with notes file Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: gejoed at rediffmail dot com Target Milestone: --- Hi team, In my org project we use gcc/gcov which is customised by another team. However with version 11.4.0 we did see a '.gcda:stamp mismatch with notes file' while running gcov tool. The same command goes fine with the previous branch code which uses gcc 10.3.0. Example of the command would be like : /gcov -l src-file.c -o ./src-file-obj-dir-path src-file.gcda:stamp mismatch with notes file File 'src-file.c' Lines executed:0.00% of 36 Creating 'src-file.c.gcov' File '../../abcd/ef/hijk.h' Lines executed:0.00% of 2 Creating 'src-file.c##hijk.h.gcov' File '../include/lmno.h' Lines executed:0.00% of 2 Creating 'src-file.c##lmno.h.gcov' Lines executed:0.00% of 40 This is seen for several files in the new branch of code where gcc v11.4.0 is used and not seen with older branch where the gcc version is 10.3.0. We generate the gcov based image (compiled with --coverage in CFLAGS) , load the image on the device, do testing, collect gcda files from device and put it back in the same obj-dir location and run the gcov tool to get the gcov files (ie. :src-file.c.gcov). I checked the gcov-dump of the respective gcda and gcno file and saw different stamp values. $gcov-dump ./obj-dir-path/src-file.gcda ./obj-dir-path/src-file.gcda:data:magic `gcda':version `B14*' ./obj-dir-path/src-file.gcda:stamp 2912455990 : $ gcov-dump ./obj-dir-path/src-file.gcno ./obj-dir-path/src-file.gcno:note:magic `gcno':version `B14*' ./obj-dir-path/src-file.gcno:stamp 2912494680 : --- For same file gcno & gcda files in the older branch (where it is gcc10.3.0) the gcov-dump gives same value : $gcov-dump src-file.gcda src-file.gcda:data:magic `gcda':version `B03*' src-file.gcda:stamp 3176078538 <.> $gcov-dump src-file.gcno src-file.gcno:note:magic `gcno':version `B03*' src-file.gcno:stamp 3176078538 I checked if any recompilation of the src file happens (from the build logs) and I couldn't see any difference between the logs of branches using v11.4.0 and v10.3.0. Do we need to check anything more on why gcda stamp value in the newer branch(using gcc v11.4.0) is getting different from the gcno value ? Was there any specific enhancement with 11.x version which would be causing the issue or is there any further check to be done during the compilation with --coverage or during the gcov tool run ? Thank you team for your support always !
[Bug gcov-profile/114735] Gcov not working with gcc version 11.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735 --- Comment #9 from Gejoe --- Thank you Andrew. Meanwhile any idea if the support person is on leave for this query : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751; Thanks again. -Gejoe From: pinskia at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org Sent: Fri, 19 Apr 2024 09:55:38 To: gej...@rediffmail.com Subject: [Bug gcov-profile/114735] Gcov not working with gcc version 11.4.0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- I will try to add something to https://gcc.gnu.org/gcc-11/porting_to.html in the next few weeks. -- You are receiving this mail because: You reported the bug.
[Bug gcov-profile/114735] Gcov not working with gcc version 11.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735 --- Comment #7 from Gejoe --- Thanks Andrew. It would be better to document this change post gcc11 apart from a sample example as generally it is understood that --coverage flag is enough for gcc to get coverage enabled build done and then gcov run post execution. This split of the job now into 2 is not very much evident (as it is only mentioned in the example and people like me will assume that was there earlier as well and won't notice the change)and hence the suggestion.
[Bug gcov-profile/114751] .gcda:stamp mismatch with notes file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 --- Comment #3 from Gejoe --- Can I get a reply on what needs to be checked next ? Thank you for the support team !
[Bug gcov-profile/114751] .gcda:stamp mismatch with notes file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 --- Comment #2 from Gejoe --- For me, it is like this (just keeping the sample filenames as such but the values are real ones shown while checking with gcov-dump) : $gcov-dump ./obj-dir-path/src-file.gcda ./obj-dir-path/src-file.gcda:data:magic `gcda':version `B14*' ./obj-dir-path/src-file.gcda:stamp 2912455990 : $ gcov-dump ./obj-dir-path/src-file.gcno ./obj-dir-path/src-file.gcno:note:magic `gcno':version `B14*' ./obj-dir-path/src-file.gcno:stamp 2912494680 : Does this indicate something more to be checked ? In the previous branch where gcc 10.3.0 is used, I could see same stamp value for the gcov-dump of same gcda and gcno files there - 3176078538. Awaiting reply. Thanks.
[Bug gcov-profile/114751] New: .gcda:stamp mismatch with notes file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 Bug ID: 114751 Summary: .gcda:stamp mismatch with notes file Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: gejoed at rediffmail dot com Target Milestone: --- Hi team, In my org project we use gcc/gcov which is customised by another team. However with version 11.4.0 we did see a '.gcda:stamp mismatch with notes file' while running gcov tool. The same command goes fine with the previous branch code which uses gcc 10.3.0. Example would be like : /gcov -l src-file.c -o ./src-file-obj-dir-path src-file.gcda:stamp mismatch with notes file File 'src-file.c' Lines executed:0.00% of 36 Creating 'src-file.c.gcov' File '../../abcd/ef/hijk.h' Lines executed:0.00% of 2 Creating 'src-file.c##hijk.h.gcov' File '../include/lmno.h' Lines executed:0.00% of 2 Creating 'src-file.c##lmno.h.gcov' Lines executed:0.00% of 40 This is seen for several files in the new branch of code where gcc v11.4.0 is used and not seen with older branch where the gcc version is 10.3.0. We generate the gcov based image (compiled with --coverage in CFLAGS) , load the image on the device, do testing, collect gcda files from device and put it back in the same obj-dir location and run the gcov tool to get the gcov files (eg :src-file.c.gcov). We checked the time stamp of gcda vs gcno files and even then the issue was seen. Was there any specific enhancement with 11.x version which would be causing the issue or is there any further check to be done during the compilation with --coverage or during the gcov tool run ? Due to my organisation restriction, I'm not able to give more info on the file names used and the make file info but I can try the best to get the info for your understanding. Awaiting valuable reply. Thank you team for your support always !
[Bug gcov-profile/114735] Gcov not working with gcc version 11.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735 --- Comment #5 from Gejoe --- my previous message is after seeing this change : https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/doc/gcov.texi;h=22e42da2ea66db568e6c563c4f2e619fe2c9ae92;hp=61250c9407e1d0e49a693d0fcc4e4c38d0e6afff;hb=452283bd060eb9bae41199b4b5e7266155d40e12;hpb=862b9b225fba6cf3c63234206f2dbc47f1ab5350
[Bug gcov-profile/114735] Gcov not working with gcc version 11.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735 --- Comment #4 from Gejoe --- Thanks Andrew for the info. So, does this mean that every program which was compiled earlier with one step (ie. gcc --coverage srcfile.c) of gcc/g++ will have to be split to 2 steps using -c option first and then processing the '.o' file ? Is this change documented in the GCC gcov manual well ? https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html I just happened to see that example today in the "Invoking Gcov" section and was thinking if this has to be done going forward for all recent gcc versions (post 11.0) or is just confined to version 11.x gcc.
[Bug gcov-profile/114735] Gcov not working with gcc version 11.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735 --- Comment #2 from Gejoe --- May I know where the fix has gone to , meaning the gcc version which will not have this issue of gcov failure ?
[Bug gcov-profile/114735] New: Gcov not working with gcc version 11.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735 Bug ID: 114735 Summary: Gcov not working with gcc version 11.4.0 Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: gejoed at rediffmail dot com Target Milestone: --- Created attachment 57955 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57955=edit Gcov runs on a sample program When I try to run a sample program with gcov of version 11.4.0 it fails as shown in the attached file. The same program runs fine with the default gcc version of 8.5. I download and installed gcc version 11.4.0 yesterday locally in my system. Snippet from the attached file: $ls a.out a-sample-prog.gcda a-sample-prog.gcno sample-prog.c $ $ $/workspace/tools/GCC/gcc-11.4.0-bld/bin/gcov sample-prog.c sample-prog.gcno:cannot open notes file sample-prog.gcda:cannot open data file, assuming not executed No executable lines - I could see the gcno and gcda files having prefix of 'a-' and probably the reason of the gcov failure(?). However this was not seen with version 8.5 of gcc.
[Bug gcov-profile/111038] The function summary in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111038 --- Comment #3 from Gejoe --- Not sure of that..Will have to check.
[Bug gcov-profile/111038] The function summary in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111038 --- Comment #1 from Gejoe --- The document referred was this: https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html Kindly respond to my query. Eagerly awaited. :) Thank you very much team for the support !
[Bug gcov-profile/111038] New: The function summary in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111038 Bug ID: 111038 Summary: The function summary in gcov Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: gejoed at rediffmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- The GNU GCOV documentation talks about -f option : -f --function-summaries Output summaries for each function in addition to the file level summary. In my case, -f is used and I could see some lines with more than 100% use. examples would be like : Function abcd_func1' Lines executed:140.00% of 5 Function 'efgh_func2' Lines executed:56.25% of 16 File 'filename.c' Lines executed:16.87% of 83 Creating 'filename.c.gcov' Here , the abcd_func1 is shown to have 140% of 5 lines. How do we interpret this ? There were other cases of 800%, 1400% etc... Is it because of the number of times hit during the execution cycle with the executable ? Let me know. Thanks! -Gejoe
[Bug gcov-profile/110545] gcda files not generated for some shared libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110545 --- Comment #3 from Gejoe --- Any other comment or suggestion here for this case ?
[Bug gcov-profile/110545] gcda files not generated for some shared libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110545 --- Comment #2 from Gejoe --- No, they are not using dlopen. The shared libraries are built and loaded during the program (image) loading.
[Bug gcov-profile/110545] New: gcda files not generated for some shared libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110545 Bug ID: 110545 Summary: gcda files not generated for some shared libs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: gejoed at rediffmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- I work on a code where shared libs (xxxlib.so) are being used. During the build --coverage is used (for compiling, linking and for shared libs) and the .gcno files are generated correctly for the source files (involved with the shared libs). For one particular module, I could find out that gcda files are not getting generated on the device. As the binary is loaded on the test device, the gcda files are generated using __gcov_dump() call and I could see gcda files being generated for many files. The __gcov_dump() is invoked through a command on the device and it completes as usual without any error message. I did a strings check for the libraries of the particular module of interest (say A123) and the gcda file paths were embedded in them. I saw that the hardwired path contained relative paths in between like /topdir/nextdir/A123/subcomp1/src/../../build/subcomp1/src/filename.gcda I did make sure that the paths for the component gcda files are made on the device like both these dir paths (as ../.. was used in the path) : /topdir/nextdir/A123/subcomp1/src/ /topdir/nextdir/A123/build/subcomp1/src/ These files get used during the loading of the image and also during the usage of some show commands on the test device which was done prior to gcov_dump execution.The directories have the write permission. However, I could see gcda files getting generated for source files linked with some other shared libraries( say /topdir/anotherdir/B123/subcomp1/obj-files/ ). Sorry that I'm not able to give more info on the original files due to the company policy. Let me know if I need to check anything further for this specific module or in the execution place/device OR if anything is not clear with my description here.
[Bug gcov-profile/104685] multiple common of `__gcov_var'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104685 --- Comment #3 from Gejoe --- Thank you Richard for your valuable inputs. That helps !!
[Bug gcov-profile/104685] New: multiple common of `__gcov_var'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104685 Bug ID: 104685 Summary: multiple common of `__gcov_var' Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: gejoed at rediffmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- In the code that I work on, in my organization the gcov build was successfully done with shared libs using the --coverage flags. However, the -Wl,--warn-common option was enabled and also the -Wl,--fatal-warnings during the linking stage. The multiple symbol common warning appeared as follows : /xxx-linux/8.2.0/real-ld: lib.so and /xxx-linux/8.2.0/libgcov.a(_gcov.o): warning: multiple common of `__gcov_var' If I remove the --fatal-warning flag, the warning appears and build succeeds. I also tried adding -Wl,--allow-multiple-definition (with --warn-common and --fatal-warnings present) but that didn't resolve the build failure. I went through ld options available and couldn't find out any solution here. Is the only solution - to turn of --warn-common option or --fatal-warning option ? Since I couldn't make a local working example myself, please bear with my query having just one line statement of the warning above (due to info sec limitations). Let me know if you would be able to help here. Thanks
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #24 from Gejoe --- Thank you Martin for all the info. Kindly bear with me for the delayed acknowledgement.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751
--- Comment #21 from Gejoe ---
(In reply to Martin Liška from comment #20)
> > I'm trying to understand line #22 to #26 specifically of .c.gcov file(as
> > shown in commment #16. Let me know if the steps followed in compilation or
> > execution had any thing wrong.
>
> What is wrong with that? What values are expected?
Actually if we look at line #22 should have the value 16 (after a.out run) and
line #24,25 should have values 4 each instead of what is actually present there
in comment#16.Instead the value of 16,4,4 are shown for line # 24,26,27
respectively. That was my query.
Is that because of some difference with source files and .gcda files as shown
there (in .c.gcov file in Comment #16) as follows ?
0:Source is newer than graph
I did delete the gcda file and did the same compilation steps again :
$ gcc -v -save-temps -fprofile-arcs -ftest-coverage sample-prog.c
$ gcc -fprofile-arcs -ftest-coverage sample-prog.o
$./a.out
The output was :
$ ./a.out
__gcov_dump() invoked!
__gcov_reset() invoked!
__gcov_dump() invoked!
__gcov_reset() invoked!
The sample-prog.c.gcov file contents now look fine :
-:0:Source:sample-prog.c
-:0:Graph:sample-prog.gcno
-:0:Data:sample-prog.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:#include
-:3:#include
-:4:
-:5:extern void __gcov_reset(void);
-:6:extern void __gcov_flush(void);
-:7:extern void __gcov_dump( void);
-:8:
1:9:int main()
-: 10:{
-: 11:unsigned char c;
1: 12:int count=0;
1: 13:c = 'g';
-: 14:
-: 15:do {
-: 16:
10: 17:if(c == 'g'){
2: 18:__gcov_dump();
#: 19:printf("__gcov_dump() invoked!\n");
#: 20:c = 'r';
-: 21:}
8: 22:else if(c == 'r'){
#: 23:__gcov_reset();
2: 24:printf("__gcov_reset() invoked!\n");
2: 25:c = 'f';
-: 26:}
10: 27:if(count == 2)
1: 28:c = 'g';
9: 29:else if (count > 10)
1: 30:c = 'e';
10: 31:count++;
10: 32:}while(c != 'e');
-: 33:
1: 34:return 0;
-: 35:}
==
So, for either a one time call of __gcov_dump (though we may attempt to call
__gcov_dump many times) or at the exit of the program execution, the merge of
profile happens due to which __gcov_reset doesn't get reflected at all. Am I
right ?
Thanks again!
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #19 from Gejoe --- Just to add on : The a.out was run twice and hence the value of 20 against line # 19, 29 of .c.gcov file(as shown in commment #16). Let me know if anything is not clear.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #18 from Gejoe --- (In reply to Martin Liška from comment #14) > (In reply to Gejoe from comment #13) > > I modified my sample-prog.c file just by adding a line of __gcov_reset > > before the while loop. > > > > Can you please create a test-case that does not need human interaction > (remove getchar please)? Thanks. I have attached the .c file as attachment 50881 in Comment #16. I have shown the steps and .gcov file output there as well. The preprocess file is attached as #50882. I read your reply in Comment#15 as well. I'm trying to understand line #22 to #26 specifically of .c.gcov file(as shown in commment #16. Let me know if the steps followed in compilation or execution had any thing wrong. Thank you for the support !
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #17 from Gejoe --- Created attachment 50882 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50882=edit sample-prog.i file Preprocessed file contents.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751
--- Comment #16 from Gejoe ---
Created attachment 50881
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50881=edit
sample-prog.c edited to show __gcov_reset call.
The steps used for compiling and running the attached .c file are as follows:
gcc -v -save-temps -fprofile-arcs -ftest-coverage sample-prog.c
gcc -fprofile-arcs -ftest-coverage sample-prog.o
./a.out
The output of a.out run is :
__gcov_dump() invoked!
__gcov_reset() invoked!
__gcov_dump() invoked!
__gcov_reset() invoked!
$ gcov sample-prog.c
sample-prog.c:source file is newer than notes file 'sample-prog.gcno'
(the message is displayed only once per source file)
File 'sample-prog.c'
Lines executed:83.33% of 18
Creating 'sample-prog.c.gcov'
$ cat sample-prog.c.gcov
-:0:Source:sample-prog.c
-:0:Graph:sample-prog.gcno
-:0:Data:sample-prog.gcda
-:0:Runs:2
-:0:Programs:1
-:0:Source is newer than graph
-:1:#include
-:2:#include
-:3:#include
-:4:
-:5:extern void __gcov_reset(void);
-:6:extern void __gcov_flush(void);
-:7:extern void __gcov_dump( void);
-:8:
2:9:int main()
-: 10:{
-: 11:unsigned char c;
2: 12:int count=0;
2: 13:c = 'g';
-: 14:
-: 15:do {
-: 16:
-: 17:if(c == 'g'){
-: 18:__gcov_dump();
20: 19:printf("__gcov_dump() invoked!\n");
4: 20:c = 'r';
#: 21:}
#: 22:else if(c == 'r'){
-: 23:__gcov_reset();
16: 24:printf("__gcov_reset() invoked!\n");
#: 25:c = 'f';
4: 26:}
4: 27:if(count == 2)
-: 28:c = 'g';
20: 29:else if (count > 10)
2: 30:c = 'e';
18: 31:count++;
2: 32:}while(c != 'e');
20: 33:
20: 34:return 0;
-: 35:}
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751
--- Comment #13 from Gejoe ---
I modified my sample-prog.c file just by adding a line of __gcov_reset before
the while loop.
However after a.out run , the sample-prog.c.gcov file was still showing the
counters though I didn't give 'g' for __gcov_dump invocation.
Quoting a portion from sample-prog.c.gcov file :
#:9:int main()
-: 10:{
-: 11:unsigned char c;
-: 12:int result;
#: 13:unsigned char data[]={127,49,255,255};
#: 14:c = '5';
-: 15:
#: 16:__gcov_reset();
<<<
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #12 from Gejoe --- Thanks for all the info. > Btw. why do you need calling __gcov_dump and __gcov_reset manually? How is > your training run special? Actually I work for a firm where the program runs on a device continually and we get the .gcda files from the device using a command which in turn invoked __gcov_dump(). Similarly to reset all the counters, we thought of using __gcov_reset after a __gcov_dump. We tar up the gcda files and take to the source code where gcov is run.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #8 from Gejoe --- (In reply to Martin Liška from comment #6) > Yes, __gcov_reset is supposed to be called at the beginning when an > application wants to start > profiling. Again, you don't need to call it manually. But reset comes into a picture where something has happened already and then the result needs to be cleared, isn't it ? At the application start, applying a reset would not make sense I think. gcov_reset would be sensible only after a gcov_dump , isn't it ? Let me know if I miss the actual design/flow of these functions. Thanks !
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751
--- Comment #5 from Gejoe ---
Running the program:
./a.out
g
When g is passed, return value is 8
When
is passed, return value is 0
r
When r is passed, return value is 8
When
is passed, return value is 0
<< the program is still running, waiting for next character entry>>
Now if we see the sample-prog.c.gcov file , it shows :
-: 16:do {
-: 17:
4: 18:c = getchar();
4: 19:result = isalnum(c);
4: 20:printf("When %c is passed, return value is %d\n", c,
result);
-: 21:
4: 22:if(c == 'g')
2: 23:__gcov_dump();
2: 24:else if(c == 'r')
#: 25:__gcov_reset();
-: 26:
3: 27:}while(c != 'c');
Looking at line 25, it doesn't show the line is hit (by giving 'r' character
during a.out run) nor are the counter values reset for the other lines. The
count of 4,3,2 are seen for some lines because of a previous a.out run.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #4 from Gejoe --- (In reply to Martin Liška from comment #3) > > For the second time and then onwards, __gcov_dump() invocation (by giving > > 'g' character during the a.out run) doesn't happen. > > Yes, one can call __gcov_dump only once per run. So, I understand that __gcov_dump could be used only after doing all the testing with the application ,i.e- towards the end to get the profile/coverage info. Am I right? > > Another thing is that, __gcov_reset() also doesn't appear to work. I tried > > giving the character 'r' during the run of the program but couldn't see the > > counters getting reset to 0 in the sample-prog.gcov file. The previous > > values of lines covered were there. > > No, __gcov_reset resets run-time counters (profile collected so far during > an application run). If you want to clear profile, then simply remove .gcda > files. Resetting run-time counters - does that mean it would not get reflected in .gcda files or the .c.gcov file contents created by gcov (assuming that the application a.out is still on run )?
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #2 from Gejoe --- Created attachment 50866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50866=edit sample-prog.c file that may be useful for gcov usage test The original sample source file.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 Gejoe changed: What|Removed |Added CC||gejoed at rediffmail dot com --- Comment #1 from Gejoe --- Created attachment 50865 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50865=edit Preprocessing logs giving gcc version
[Bug gcov-profile/100751] New: __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 Bug ID: 100751 Summary: __gcov_dump and __gcov_reset usage Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: gejoed at rediffmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 50864 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50864=edit sample-prog.i which is the preprocessed version of sample-prog.c I did go through the online manual of gcc gcov on __gcov_dump() and __gcov_reset() : https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html#Gcov-and-Optimization I tried out using the functions in a sample program (sample-prog.c) that is attached here. The steps followed were : (1) gcc -fprofile-arcs -ftest-coverage sample-prog.c (2) ./a.out (3) gcov sample-prog.c While running a.out, when I give character 'g', the __gcov_dump() must be invoked. What I could observe is that first time __gcov_dump() is invoked , the sample-prog.gcda file gets created. For the second time and then onwards, __gcov_dump() invocation (by giving 'g' character during the a.out run) doesn't happen. This is concluded by looking at the time stamp of sample-prog.gcda file in the same folder. It was still having the same time stamp of first time invocation of __gcov_dump(). Another thing is that, __gcov_reset() also doesn't appear to work. I tried giving the character 'r' during the run of the program but couldn't see the counters getting reset to 0 in the sample-prog.gcov file. The previous values of lines covered were there. Let me know if my approach is correct or if I miss any information here. I'm attaching the preprocessed file (sample-prog.i) and the logs of the gcc step used for the preprocessed file.
