Cross profiling with gcov, but GCOV_PREFIX and GCOV_PREFIX_STRIP are ignored

Question

I want to use GCOV to cover the code, but the tests will run on another computer. Thus, the hard-wired path to the .gcda files in the executable will not work.

To change this default directory, I can use GCOV_PREFIX and GCOV_PREFIX_STRIP env vars, as said here .

Here are my commands that I used:

$ export GCOV_PREFIX="/foo/bar" $ export GCOV_PREFIX_STRIP="3" $ gcc main.c -fprofile-arcs -ftest-coverage $ strings a.out | grep gcda /home/calmarius/blahblah/main.c.gcda 

The path remains unchanged. Anyone have experience with this?

Answer 1

Environment variables are taken into account when running the code.

Before running the tests, set them to the appropriate values ​​on the target computer, and the .gcda files will be created where you want.

Answer 2

************ ARRRRGGGGGGHHHH ************

Please vote for the answer Mat.

Environment variables are taken into account when running the code.

This one sentence is apparently missing from EVERY document I read about how to transfer output!

In fact, let me expand this answer a bit.

GCOV_PREFIX is the runtime — as indicated by the build-time variable — the environment determines the root directory in which the gcov output files (* .gcda) are written.

GCOV_PREFIX_STRIP = X is also a run-time variable and has the effect of removing X elements from the path found in object files (lines XXXX.o)

What does it mean:

When you create your project, the object files are written with the full path to the location of each source file responsible for each object file embedded in them.

So, imagine that you write the MyApp executable and the MyLib library in a directory line as follows:

 /MyProject |-MyApp |--MyLib 

MyLib notification is a MyApp subdirectory

Let them say that MyApp has 2 source files, and MyLib has 3

Once created using the "-coverage" flag, you will create 5.gcno, 1 for each object file.

The nested .o files for MyApp will be the absolute path ** / MyProject / MyApp / ** a_source_file.cpp Likewise, the nested .o files for MyLib will be the path ** / MyProject / MyApp / MyLib / ** another_source_file.cpp

Now say that you look like me, and move these files to a completely different machine with a different directory structure from which they were built. In my case, the target machine is actually a completely different architecture. I am deploying to / some / deploy / path not / MyProject on this machine.

If you just run the application, the gcov data will try to write the corresponding .gcda files to / MyProject / MyApp and / MyProject / MyApp / MyLib for each object file in your project, because the path specified by the .o files, and finally, MyApp and MyLib is simply collections of .o files archived together, with other magic to fix pointers, etc.

Most likely, these directories do not exist, and you probably do not use them as root (you?), Therefore these directories will not be created either. Soooo .. you will not see any gcda files in the deployment location / my / deploy / path.

This is completely confusing, right!?! ??!?!?!?

Here, where are GCOV_PREFIX and GCOV_PREFIX_STRIP.

(BAM! Fist beats his forehead) You need to tell **** runtime **** that the embedded path in the .o files is not quite what you want. You want to “delete” part of the path and replace it with the deployment directory.

So you set the deployment directory via GCOV_PREFIX = / some / deploy / path and you want to remove / MyProject from the generated .gcda paths so that you set GCOV_PREFIX_STRIP = 1

Using these two environment variables, you launch your application, and then look at / some / deploy / path / MyApp and / some / deploy / path / MyApp / MyLib, and now, 5 gcda files miraculously appear, one for each object file .

Note: the problem is exacerbated if you are not using the source builds .. o points to the source, but gcda will be written relative to the build directory.