What is the second number in BRDA? And why it is changed after merging tracefiles?

[myler]

I have two tracefile, one contains data collected on Linux, another contains data collected on Windows. After I used -a option to merge them into one overall tracefile, I found some BRDA's second number changed:
BRDA:7,0,2,0 changed to BRDA:7,1,2,0 if the Linux tracefile is behind Windows tracefile with -a option, vice versa.

[henry2cox]

man geninfo

[myler]

It seems no doc related to changing of block number in geninfo manpage, not sure the tool can recognize same branch of template instances built on Windows and Linux.

[myler]

https://github.com/linux-test-project/lcov/blob/master/lib/lcovutil.pm#L5230, this is what I searched, no chance to control the block number.
When we merge multiple tracefiles win_test.info, lin_test.info, ..., etc, we lose the information of the original branch, so that we cannot use BRDA data to track subsequent work, such as adding new tests to a uncovered branch.

[myler]

@henry2cox, I see you already added test https://github.com/linux-test-project/lcov/tree/master/tests/lcov/branch to cover this usage. For branch of template instances, the order of merging tracefiles definitely affects order of BRDAs. (The total number of BRDAs is not changed).

So, is there a sustainably way (e.g., unique id or mangled expr?) to track a branch is taken or not if we continuously merge new tracefiles?

[henry2cox]

If I understand the question, then I think I don't quite understand the issue you see.

Some background.
As you point out, the blockId is used to distinguish:

1. distinct conditionals which appear on the same line in the source code - e.g., foo = bar(a || b, c && d);, and
2. different conditionals which arise from the same statement - either:
   * in different compilation units (due to macro expansion) or
   * in different template instantiations (typically short-circuited Booleans involving template parameters)
   (unlike branch data, MC/DC data generated by gcc/14 doesn't have this issue).

The branch expression (if known) is used to decide who matches who.
It happens that certain languages (perl, Python, (System)Verilog) explicitly identify each branch expression (as a string - say a && !b) - but gcov-generated data for C/C++ does not. In gcov output, the branch expression is just an integer (related to expression traversal order in the compiler). This can be ambiguous when the same source line is used in multiple compilation units or when code changes over time.

lcov tries to sort this out in a couple of ways.

For the first case, it assumes that the order of gcov-generated output data for expressions on a particular line is the same in every result file. In this case, it also assumes (and checks) that the total number of distinct expressions (the number of distinct blockIds) and the number of branch records in each block is the same in each data file - and that the branch expressions (if known) are the same.

In the second case: it assumes that the related conditional is the same if the number of branch records and their branch expressions are the same.

Unfortunately: it isn't hard to see that there isn't sufficient information in the output data for lcov to distinguish the first and second cases.
Ambiguity is the result. :-(
Usually, this isn't too hard for a human to figure out - but it also depends on your infrastructure and your requirement - particularly if you are in a very high reliability environment.
In our environment, we find the coverage data to be actionable - but you may have a more complicated environment such that the tools are not sufficiently repeatable to create actionable results.

You mentioned that you are using windows - but you didn't mention your toolchain and toolchain version, or what the source of your input .info file data is (generated by gcc -> lcov(gcov) ? llvm -> llcov(llvm-cov)? llvm -> llvm-profdata -> llvm-cov? Something else?

Without seeing your actual data (or a representative small testcase), I am not sure what to suggest.
It is always possible that there is a bug in lcov data handling - and it isn't doing what it is supposed to be doing.
It is also possible that there are bugs in in gcov (or llvm-cov, or whatever extract tool you are using.)

Henry

[myler]

Thank you so much for this detail answer and so quick reply!!! This is very useful to me to understand how lcov works now.

but you didn't mention your toolchain and toolchain version

I‘m using Intel compiler (which is derived from llvm/clang), and the coverage data format is .gcno, and .gcda emitted by llvm-cov gcov.

Without seeing your actual data (or a representative small testcase)

Suppose we are comparing BRDAs in line 7 of example code:
Linux:

BRDA:7,0,0,- (line 23 never executed on Linux)
BRDA:7,0,1,- (line 23 never executed on Linux)
BRDA:7,0,2,0
BRDA:7,0,3,1

Windows:

BRDA:7,0,0,0 (line 16 only build on Windows)
BRDA:7,0,1,1 (line 16 only build on Windows)
BRDA:7,0,2,0
BRDA:7,0,3,1
BRDA:7,0,4,- (line 25 never executed on Windows)
BRDA:7,0,5,- (line 25 never executed on Windows)

Merged order linux info, then windows info: (lcov -a linux.info -a windows.info -o merged.info)

BRDA:7,0,0,-
BRDA:7,0,1,-
BRDA:7,0,2,0
BRDA:7,0,3,1
BRDA:7,1,0,0 (the <block number> changed from 0 to 1 after merging two info files if windows info file is after linux info file)
BRDA:7,1,1,1 (same as above)
BRDA:7,1,2,0 (same as above)
BRDA:7,1,3,1 (same as above)
BRDA:7,1,4,- (same as above)
BRDA:7,1,5,- (same as above)

Merged order windows info, then linux info: (lcov -a windows.info -a linux.info -o merged.info)

BRDA:7,0,0,0
BRDA:7,0,1,1
BRDA:7,0,2,0
BRDA:7,0,3,1
BRDA:7,0,4,-
BRDA:7,0,5,-
BRDA:7,1,0,- (the <block number> changed from 0 to 1 after merging two info files if linux info file is after windows info file)
BRDA:7,1,1,-
BRDA:7,1,2,0
BRDA:7,1,3,1

The example code is very simple, but suppose we have complex conditions in real project which the branch in line:7 are multiple conditions and some of them are not covered (neither some platform-specific template instantiations nor code logic depends on different platforms). Then, we plan to write more test cases to improve coverage. But when we run test cases to generate new coverage data, how can we know which branch coverage got improvement? BRDA:7,1,2,0 or BRDA:7,0,2,0.

[henry2cox]

The first integer after "BRDA:" is the source line number.
All your numbers are "7" 0 for lines 16, 25, and so forth.

Your compiler/toolchain is broken and is generating bogus branch information.

You should try to upgrade to a newer version - and see if that addresses the issue.
Or move to LLVM or GCC. Both work better.

[myler]

All your numbers are "7" 0 for lines 16, 25, and so forth.

Sorry, this makes confusion, I just removed unrelated output, only kept line: 7 here.
As you can see, the second field <block number> changed from 0 to 1 for appended .info file.

[henry2cox]

Your first block (numbrerd 0) has 6 branch tokens.
Your second has 4.
They are not the same - so they don't get merged.

The block ID is not meaningful - except block IDs on a particular line are unique.
When merging: lcov will look at a block containing 4 branch tokens and attempt to merge it with a block from the other DB which also has 4 branch tokens (if the branch expressions are identical. For gcov generated branch data: there is no branch expression - just an integer visit order index. Those are going to be identical for any block containing 4 tokens.)

Rather than hacking up data manually and trying to illustrate some point, it is far better - and far easier for both of us - to instead show a complete example (with source code and makefiles). Then we know that we are both looking at valid, tool-generated data, and that we are both seeing the same issues.

[myler]

Let me show complete example:

Environment:

Linux OS: Red Hat Enterprise Linux 9.0 (Plow)
Window OS: Windows Server 2025 Standard 24H2

Compiler version:

Linux

> clang++ --version
clang version 21.0.0git (3215fd70294369b73b0e944238097a28550e7435)

Windows

> clang-cl --version
clang version 21.0.0git (3215fd70294369b73b0e944238097a28550e7435)

llvm-cov:

> llvm-cov --version
LLVM (http://llvm.org/):
  LLVM version 21.0.0git

> cat llvm-gcov.sh
llvm-cov gcov "$@"

lcov version:

> lcov --version
lcov: LCOV version 2.2-beta

Attached gcov_example.tar.gz
Please unpack it by tar -xzf gcov_example.tar.gz and see .gcno, .gcda, test.cpp, llvm-gcov.sh, and .info files.

Build commands

Linux:

> clang++ -coverage test.cpp
> ./a.out
> ls
a.out a-test.gcda  a-test.gcno  test.cpp

Windows:

> clang-cl --version
clang version 21.0.0git (3215fd70294369b73b0e944238097a28550e7435)

> clang-cl --coverage test.cpp
> test.exe
> dir /b
a-test.gcda
a-test.gcno
test.cpp
test.exe

# scp a-test.gcda a-test.gcno test.exe to Linux `shared` directory and run lcov to generate `windows.info`

Generate tracefile

In order to keep SF: as same to avoid running on different path of different machines, we copy gcov data in share directory before running lcov.
Linux

> cp lin/a-test.gcda  lin/a-test.gcno share/
> cd share
> lcov --capture --directory . --branch-coverage --ignore-errors source,inconsistent --no-external --gcov-tool ./llvm-gcov.sh -o ../linux.info

Windows

> rm share/a-test.gcda share/a-test.gcno
> cp win/a-test.gcda  win/a-test.gcno share/
> cd share
> lcov --capture --directory . --branch-coverage --ignore-errors source,inconsistent --no-external --gcov-tool ./llvm-gcov.sh -o ../windows.info

Merge tracefiles

> lcov --branch-coverage  --gcov-tool ./llvm-gcov.sh -a ./linux.info -a ./windows.info -o merged_lin_win.info
> lcov --branch-coverage  --gcov-tool ./llvm-gcov.sh -a ./windows.info -a ./linux.info -o merged_win_lin.info