Unable to generate gcda file for cc_library_shared module about lcov HOT 3 OPEN

If I understand your environment: I think that we do exactly this, successfully. (Build coverage-instrumented shared library, use that library in a bunch of executables - generate unified coverage report across all the executables and all the tests.)

Maybe try to walk before you run:

• does your data build successfully/what happens when you do not use GCOV_PREFIX?
  Why do you think you need GCOV_PREFIX (there are valid reasons to use it - just wondering if your case is one of them).
• does a very simple project (say, one source file in each of two directories) do what you expect when you do use GCOV_PREFIX?

I guess you know that the runtime coverage data (the .gcda files) are generated only after running your executable - and only if it exits normally. Is the code missing from your data actually used/linked in your test executable? Did your tests run?

You did not mention platform or tool versions.

You are more likely to get a useful answer if you provide a small testcase that exhibits the issue you are seeing.

from lcov.

Thank you for your reply.

1. My data build successfully.
2. The result is the same when I don't use GCOV-PREFIX and when I use GCOV-PREFIX, gcda will be generated in the /data/ because I have set fpprofile-dir=/data/ in both the bp and mk files, and set export GCOV_PREFIX=/data/ to be more secure.
3. one source file in each of two directories, when I use GCOV_PREFIX=/data/, the gcda files are generated under /data/, such as /data/name1/test/dir1/test1.gcda, /data/name1/test/dir2/test2.gcda

But there is no corresponding /data/source.cpp for /data/source.gcda, I confirm that both test1.cpp and test2.cpp have called functions in source. cpp.

from lcov.

I guess you realize that this is a compiler/toolchain issue - not an lcov issue.
You may get better results by asking your question in a clang/llvm group.
You will also get better results if you include a small testcase - or even a large testcase - which illustrates the issue you are seeing.
Ideally, such a testcase would include a small handful of source files and a makefile or shellscript which builds your example application, runs your tests, and then indicates which data is missing.
Without such an example, it is impossible to know what you did - maybe there is a problem in your setup, you used wrong parameters - and impossible to know what happened.

I do not know how -fprofile-dir and GCOV_PREFIX interact. We use one or the other - not both (the former to use the 'llvm profile' coverage data flow, and the latter to use the 'gcov data' coverage flow).

I suggest to start with a small example and build up slowly until you see an error that looks like what you see with your actual application - then you can either debug the issue, or include the example when asking for help. One possible "building up" sequence is:

• two source directories 'srsandlib`, one source file in each.
• build all the .o and explicitly link them - say, with --coverage (gcov flow) and with -fprofile-instr-generate -fcoverage-mapping (profdata flow).i
  Does coverage data get generated as you expected (say, with and without GCOV_PREFIX, with and without profile redirection)?
• archive the .o from the lib directory into a static library (ar -o libstatic.a ...) - then link that with the .o from the src directory and run the experiments again.
  Did coverage data get generated as you expected?
• link the .o from the lib directory into a shared library - then link that with your .o, and see if coverage data gets generated as you expected.

Gradually make your small testcase look more and more like your actual application as you try to make your testcase fail.

If the above sounds like too much work and too much schedule uncertainty: consider hiring a consultant who is expert in this field.

from lcov.