6

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.

1
  • 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. Commented May 2, 2012 at 7:09

5 Answers 5

10

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

Sign up to request clarification or add additional context in comments.

4 Comments

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 !
I try this commands but still no gcda file out: g++ -fprofile-arcs -ftest-coverage -lgcov main.cpp Do I miss anything else?
@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.
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.
7

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

2 Comments

So is there any signal that quits the process and preserves generating .gcda files, e.g. SIGHUP or SIGINT?
@Melebius I just had the same problem and found: this. Using SIGTERM and handling sigterm as described in the link worked for me.
2

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).

Comments

2

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); .... } 

1 Comment

In case of libraries which use abort() (such as SDL), handling SIGABRT in a similar manner does the trick.
0

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.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.