Taking Notes: Understanding the GCNO dump part 1

Hello Everyone!

In my previous post I explained about the approach to get the coverage reports in gcov formats by taking the gcno files and the qemu traces. I have also mentioned about the gcno_dumper project to dump the contents of the gcno files in a human readable txt file. This project is an attempt to demystify the gcno files, which is really important in order to work with this field. You can find all the project related codes in the following repo. Currently it just contains the c++ code but I will soon add a README with the dump txt file.

https://github.com/thelunatic/gcno_dumper.git

I have already generated the 1st part of the gcno dump and in this post I will explain the txt dump obtained and how they are useful.

The txt dump I’m going to explain, has been generated by running the gcno_dump on score/src/libscore_a-timespeclessthan.gcno you can download the gcno file from the following Google Drive link

GCNO DUMP

MAGIC    :  0x67636e6f
VERSION  :  0x41373352
TIMESTAMP:  0x5fc87a56


READING NOTE RECORDS 


FUNCTION TAG         :  1
FUNCTION LENGTH      :  29
FUNCTION IDENT       :  0x47f3d62f
LINE_NO CHECKSUM     :  0x9417fabe
CFG CHECKSUM         :  0x4f7a5af2
FUNCTION NAME LENGTH : 5
FUNCTION NAME        : _Timespec_Less_than
SOURCE NAME LENGTH   : 18
SOURCE NAME          : ../../../../../../rtems/c/src/../../cpukit/score/src/timespeclessthan.c
LINE NUMBER          : 26

• MAGIC : This is the gcno magic, used to determine the endianness of the file
• VERSION : The version number consists of two character major version number. Please have a look at this link for a detailed description of the version number.
• TIMESTAMP : The stamp value is used to synchronize note and data files and to synchronize merging within a data file. Note that this is not exact timestamp, it’s just there to distinguish different compile/run/compile cycles.
• FUNCTION TAG : The Function Tag numbers reflect the record hierarchy. [1 …3f] are used for common tags, [41..9f] for notes file and [a1..ff] for the data file.
• The rest of the information is the function-graph record. The Function length shows the number of 4-byte information that follows, this is useful to know when we’re trying to parse this file to get the function information, it gives out the total size after which the Basic_Block record starts (About this in the part 2 of this post).
• The Function Name is the name of the function under test, and the Function Name Length is basically the Total number of 4-bytes, the Function name will take.
• Similarly the Source Name is the name of the c source file where the functionis defined. And the Line Number is the line number in the source file where the function is defined.

This sums up the progress so far in understanding the gcno files. There’s surely much more to figure out to get to a point where we can successfully generate gcov reports. And the work will need to go on post GSoC as well. Before the work on gcov goes further there’s a strong need for a proper documentation of the RTEMS coverage analysis, collecting all the related informations and all the work related to coverage analysis in one place.

Thank you !