gcov not generating gcda files

Question

I tried to run gcov with -fprofile-arcs & -ftest-coverage and nothing for linking.

It was giving this error:-

 hidden symbol `__gcov_init' in /home/mojave/tools/gcc-4.4.1/amd64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgcov.a(_gcov.o) is referenced by DSO

and program exits.

Command to compile-

bsub -g /mojave/build/"DummyDate" -J compile-obj/linux24rhel3_x86_64_GCOV64/DXp.o -I -q DFM -S 8192 -R "(model==OPTERON_250)" '/usr/bin/time --format="          ...finished DXp [`hostname`] [%E s with %P CPU]"  /home/mojave/tools/gcc-4.4.1/amd64/bin/g++ -fPIC -Wall -Wno-deprecated -DTCL_8_5 -m64 -march=opteron -DLITTLE_ENDIAN_PLATFORM -DARCH=amd64 -DARCH_amd64 -DARCH_BITS=64 -DARCH_BITS_64 -fsigned-char -msse3 -D__DISABLE_MULTITHREAD__ -D_CPP_NUMERIC_LIMITS -mfpmath=sse,387 -mmmx -m3dnow -pipe -Dgcc -DLICENSE_ALWAYS_GOOD -I/home/mojave/tools/flexlm/include/v8.4 -DNO_SUPPORT_STABIE -DGCOV -I../dxpclient -I/home/mojave/tools/bzip2-1.0.2/amd64/include -I/home/mojave/tools/zlib-1.2.3/amd64/include -I/home/mojave/tools/tcltk8.5.2/amd64//include -I/home/mojave/tools/tcltk8.5.2/amd64//include -g -fprofile-arcs -ftest-coverage -DBUILD_DATE=\""UNSET"\" -DVERSION_NUMBER=\"Dum.Dum.Dum.Dummy\" -DEXT_VERSION_NUMBER=\"Dum.Dum.Dum.Dummy\" -DLAST_RELEASE_VERSION=\"1.1614\" -Wreturn-type -DTCL_8_5 -DGOOGLE_MALLOC -L../dx/linux24rhel3_x86_64_GCOV64/ -ldx -o obj/linux24rhel3_x86_64_GCOV64/DXp obj/linux24rhel3_x86_64_GCOV64/DXp.o -Wl -lgcov /home/mojave/tools/zlib-1.2.3/amd64/lib/libz.a  -L/home/mojave/tools/bzip2-1.0.2/amd64/lib -lbz2    -ldl'

Any help will be appreciated with vote up.

Thanks.

Can you show us the Makefile or the compilation string? It is quite possible that you are attaching the profile flags to wrong target object. — Shrey, May 02 '12 at 07:09

score 9 · Accepted Answer · edited Nov 25 '16 at 07:38

9

Compile with -fprofile-arcs and -ftest-coverage. Link with -lgcov during the generation of shared object. It will work.

Also you may use --coverage option as synonym for all three steps

Look at: gcc instrumentation options for more information

edited Nov 25 '16 at 07:38

Konstantin Vladimirov

6,791
1
27
36

answered May 16 '12 at 04:09

crazy_prog

1,085
5
19
34

7

Note : using `--coverage` for both compile and link automatically translates to the flags you give. This is a conveniance offered by gcc to make things easier. Also future-proof. Enjoy ! – Offirmo Oct 10 '12 at 15:01
I try this commands but still no gcda file out: `g++ -fprofile-arcs -ftest-coverage -lgcov main.cpp` Do I miss anything else? – naive231 May 23 '16 at 03:16
1

@naive231 I personally was having this issue because I had a for(;;) infinite loop at the end of my main method. The program needs to exit out for the gcda files to be generated correctly. – user3062913 May 30 '17 at 17:04
1

Even with this all set correctly, Eclipse may require the binary to be run to generate .gcda files to be generated. This may be your situation if you see .gcno files only. – user2725742 Feb 08 '21 at 21:04

score 5 · Answer 2 · answered Feb 01 '19 at 19:06

5

I just found out, if i send a sig kill or sig term to my program, ONLY GCNO FILES ARE MADE, no gcda files.

answered Feb 01 '19 at 19:06

Bradley Luke Totaro

51
1
2

2

So is there any signal that quits the process and preserves generating .gcda files, e.g. SIGHUP or SIGINT? – Melebius Aug 24 '20 at 06:28
@Melebius I just had the same problem and found: [this](https://gcc.gnu.org/legacy-ml/gcc-help/2017-08/msg00000.html). Using SIGTERM and *handling* sigterm as described in the link worked for me. – sascha Oct 03 '20 at 12:40

score 2 · Answer 3 · edited May 23 '17 at 12:24

After considering the compilation flag, as mentioned above by crazy_prog, check the "path". While taking the coverage using lcov/gcov, path plays an important role.

Therefore, the path at which you have created the binary (full path string), and the path at which you are running the binary should be exactly the same.

For my purpose, since the creation of the binary and execution of the binary is at different places (one in development environment and other in actual board), so using the softlink/shortcuts, I create similar path, and hence run the executable. Finally, one can generate the report in development environment (usually, since the actual platform on board might not have lcov tools support).

score 2 · Answer 4 · answered Feb 18 '22 at 04:55

In addition to the compile options and link options above, my input is that if you kill a program in a non grace manner, such as ctrl-c, the program will not exit cleanly, no gcda files will be generated.

So solve this problem so that gcda files will be generated even if you use ctrl-c, do below:

void handler(int signum)
{
     /* SIGTERM dnd clean up (close file descriptors, etc).  */
 
     exit(0);
}
 
int main(int argc, char *argv[])
{
    signal(SIGTERM, handler);
    signal(SIGHUP, handler);
    signal(SIGINT, handler);
    ....
}

In case of libraries which use `abort()` (such as SDL), handling `SIGABRT` in a similar manner does the trick. — Dmitry Grigoryev, Nov 22 '22 at 10:39

score 0 · Answer 5 · answered Dec 14 '22 at 21:05

I'll add something I found that was preventing me from seeing gcda files created, since none of the other answers to this or related questions were helping me.

In my case I had a file with a pragma pack that was not closed, for example:

#pragma pack(1)

typedef struct thing_t
{
    int x;
    int y;
} thing_t;

int functionA();

<END OF FILE>

When I corrected this like so:

#pragma pack(1)

typedef struct thing_t
{
    int x;
    int y;
} thing_t;

// go back to normal packing
#pragma pack()

int functionA();

<END OF FILE>

gcda files were then generated after running my test.

gcov not generating gcda files

5 Answers5

Linked