CODEWITHSUNDEEP
gccgcov
crazy_prog
crazy_prog

Reputation: 1099

gcov not generating gcda files

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.

Upvotes: 6

Views: 38980

Answers (5)

G_M
G_M

Reputation: 11

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.

Upvotes: 0

Charlie
Charlie

Reputation: 753

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

Upvotes: 2

Bradley Luke Totaro
Bradley Luke Totaro

Reputation: 71

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

Upvotes: 7

crazy_prog
crazy_prog

Reputation: 1099

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

Upvotes: 10

parasrish
parasrish

Reputation: 4152

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

Upvotes: 2

Related Questions