Handle duplicate SF in coverage.info to make sure coverage.xml gets correct statistics

[a114j0y]

What I did
use --add-tracefile option in debian/rules and tests/conftest.py to sanitize coverage.info generated by lcov

Why I did it
lcov generates an initial coverage.info file based on collected .gcno and .gcda files, this .info file contains coverage information for different source files (marked as SF). Sometimes you would observe that the same SF appears multiple times, it means lcov gets multiple copies of coverage information for this file, since this file may have appeared in multiple compilation units, and for each copy, the hit times of its lines are different.

Then lcov_cobertura generates coverage.xml based on coverage.info. However, it can't deal with duplicate SF in coverage.info properly. If it sees duplicate coverage information for a source file from coverage.info, it always overwrites the old copy with the new copy, hence only the last copy would be counted. However, if the last copy considers the functions as missing, the function is considered as missing in coverage.xml, which is used to determine whether the new PR passes the coverage threshold.

The proper way is to add the hit times of all the copies, which could be achieved by lcov add-tracefile option.

How I verified it
Before using --add-tracefile, RingBuffer related functions in this PR are considered missing, though they are covered in testcases. After adding --add-tracefile, it passes the coverage check.

[orchagent] implement ring buffer feature with a flag #3242

Details if related
By downloading the artifact of PR#3242, we could check coverage.xml, which has already had the correct statistics.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[yuezhoujk]

/azp run Azure.sonic-swss

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[a114j0y]

This coverage.zip contains the coverage.info and buggy coverage.xml obtained from artifacts of PR#3242, without the change of this PR#3482.
@saiarcot895 @theasianpianist @prsunny

you can check by searching SF:/__w/1/s/orchagent/orch.cpp in the attached coverage.info and would find 4 copies there, to be more specific, you can search FN:36,_ZN10RingBuffer6notifyEv in coverage.info, which is a function defined in orch.cpp, and would see 4 copies of FNDA there, which are 0, 0, 3, 0. It means this function is hit by 0, 0, 3, 0 times, hence a total of 0+0+3+0=3 times.

But in coverage.xml, this function is counted as hit by 0 times, because it only check the last FNDA in coverage.info.

What this #PR3482 wants to fix is that, use --add-trace-file option for lcov, so that it could sum up all FNDA to get the correct hit times for a function. Otherwise, some covered functions would be considered as missing, by mistake.

[saiarcot895]

The best fix for this is to rework the automake build files to not need to compile the same files repeatedly. This probably involves switching to non-recursive automake, and takes a bit of time to do so without breaking anything. This is a good enough short-term fix, at least.