-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[master] add Code Coverage Rate HLD #642
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: tim-rj <sonic_rd@ruijie.com.cn>
Signed-off-by: tim-rj <sonic_rd@ruijie.com.cn>
|
||
When a source file is compiled with the gcov compiling options, each executable line in this source file will be followed by a new-added piece of code that updates coverage statistics. Gcov realizes this process by adding stubs when generating assembly files. Each stub point will be inserted into 3 to 4 new assembly statements. These statements are directly added to the .s files. Then the assembly files can be assembled to the object files and the executable file. After doing this, when the executable file is running, the stubs added during compiling will collect the execution information. The statistical approach for these stubs is very simple, they are just variables in the memory and record the execution times for each code line. Therefore in the practical running environment, the performance impact brought by generating .gcda files can be ignored. The user can also hardly feel the difference.<br> | ||
|
||
# 5. Coverage data for the python script |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggest to remove section 5 since it is not gcov related.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, done!
Signed-off-by: tim-rj <sonic_rd@ruijie.com.cn>
Signed-off-by: chengzhengnan <chengzhengnan@ragilenetworks.com>
…ation Signed-off-by: chengzhengnan <chengzhengnan@ragilenetworks.com>
hi @lguohan help push forward this hld, thanks! |
…nformation in Azure pipeline platform Signed-off-by: pettershao-ragilenetworks <pettershao@ragilenetworks.com>
hi @lguohan help push forward this hld, thanks! |
@lguohan @qiluo-msft @yxieca as gcov for swss daemon is work fine and be in merging, help mege this hld, thanks! |
1 similar comment
@lguohan @qiluo-msft @yxieca as gcov for swss daemon is work fine and be in merging, help mege this hld, thanks! |
@lguohan @qiluo-msft @yxieca as gcov for swss daemon has been merged, help mege this hld, thanks! |
8498931
to
8837dc2
Compare
Code coverage rate is the term used in code testing in Ruijie commercial switch for years. It is the rate of the number of code lines has been executed divide by the number of total code lines in switch operating system. We reuse this term in SONiC code testing and create some related tools for SONiC code testing.
Ruijie use the Gcov tools to measure the code coverage rate in its commercial switch and white box switch. We create the Linux scripts for Gcov compiling, Gcov data collect, and Gcov data show functions for SONiC. A GCOV_ENABLE compiling tag is provided for SONiC code project. And we integrate all these Gcov functions into Jenkins CICD system. Our solution is a complete tool set for code coverage rate for SONiC.