I have noticed that when using gcov, some artificial functions like __cxx_global_var_init() contaminate the code coverage results. Here is a minimal reproducible example (of course, this is related to my compilation and runtime environment):
```
这里输入代码
```
#include <iostream>
intmain() {
std::cout << "Hello World!" << std::endl;
// Lots of Lines
// Line 74
return 0; // Line 75
}
I built this example using the following command (Clang version 16.0.6):
clang++ -O0 -g --coverage main.cpp
I calculated my coverage results with:
llvm-cov gcov main.cpp
The final output is:
$ :~/tmp/test_gcov_new_cases$ cat main.cpp.gcov
-: 0:Source:main.cpp
-: 0:Graph:main.gcno
-: 0:Data:main.gcda
-: 0:Runs:1
-: 0:Programs:1
-: 1:#include <iostream>
-: 2:
1: 3:int main() {
1: 4: std::cout << "Hello World!" << std::endl;
-: 5:
-: 73: // Lots of Lines
1: 74: // Line 74
1: 75: return 0;
-: 76:}
As you can see, line 74 shows an execution count despite having no content. I performed some debugging on LLVM and discovered that this incorrect count comes from a global variable on line 74 of the iostream in my local libstdc++.
image
image
2214×308 44.7 KB
=====================================
During my debugging process, I found that the __cxx_global_var_init() function generated by iostream has a corresponding filename of main.cpp in the gcno file.
image
image
1822×650 152 KB
Here, the filename uses the entire function’s filename rather than the specific filename of the subprogram for that line.
image
image
1802×760 227 KB
=====================================
I also attempted to print the IR of this program as additional evidence:
image
image
3208×712 246 KB
You can see that the file for this artificial function is !872, which corresponds to main.cpp (!10), but the specific line debug information (!874) actually belongs to iostream (!3).
image
image
3838×406 58.9 KB
image
image
3770×852 472 KB
=====================================
Furthermore, when llvm-cov reads the data, it seems to directly ignore the filename in the gcno for each file in every BasicBlock.
image
image
790×712 79.1 KB
=====================================
Is this situation caused by my incorrect usage, or should there be a change in how the filename for artificial functions is obtained (for example, switching to getDISubprogram(Loc.getScope())->getFilename())? Additionally, should logic for handling different filenames be added during the reading process in llvm-cov?
在上游社区 discourse 提供了详细的问题 [Incorrect line coverage caused by artificial functions in gcov coverage reports](https://discourse.llvm.org/t/incorrect-line-coverage-caused-by-artificial-functions-in-gcov-coverage-reports/84732)
同时在 llvm-project 提了 issue.
[Incorrect File Association in Debug Information of __cxx_global_var_init() #128149](https://github.com/llvm/llvm-project/issues/128149)
在上游社区 discourse 提供了详细的问题 [Incorrect line coverage caused by artificial functions in gcov coverage reports](https://discourse.llvm.org/t/incorrect-line-coverage-caused-by-artificial-functions-in-gcov-coverage-reports/84732)
同时在llvm-project 提了 issue.
[Incorrect File Association in Debug Information of __cxx_global_var_init() #128149](https://github.com/llvm/llvm-project/issues/128149)
openeuler-ci-bot
拥有者
