Hello, I have made the changes and also got the confusion with structure of gcno, cleared to some extent after some careful reading and experiments.
I'm attaching the txt file generated. So far it is complete up to function record, next is the basic block records. I will start with the block records after finalizing the wrapup of the non-gcov coverage reports to make sure that everything works properly there. -- vijay On 18 July 2018 at 17:17, Vijay Kumar Banerjee <vijaykumar9...@gmail.com> wrote: > On 18 July 2018 at 02:30, Joel Sherrill <j...@rtems.org> wrote: > >> This definitely looks like the right direction. If we don't understand >> the file formats, we will never be able to process and correlate them. >> >> Please put 0x in front of hex numbers. It does help. >> >> Can you explain the fields in gcno_dump.txt? The Version field >> looks like hex for R37A which doesn't make sense to me. Reading the >> header in gcov-io.h, I wonder how it matches this pattern? >> >> it should be A73R, I have corrected it. > I have tried to give some description in the code itself. > I'll write a detailed description of each field once it's complete. > Maybe a blog post will be nice. > >> ================================ >> Although the ident and version are formally 32 bit numbers, they >> are derived from 4 character ASCII strings. The version number >> consists of a two character major version number >> (first digit starts from 'A' letter to not to clash with the older >> numbering scheme), the single character minor version number, >> and a single character indicating the status of the release. >> That will be 'e' experimental, 'p' prerelease and 'r' for release. >> Because, by good fortune, these are in alphabetical order, string >> collating can be used to compare version strings. Be aware that >> the 'e' designation will (naturally) be unstable and might be >> incompatible with itself. For gcc 17.0 experimental, it would be >> 'B70e' (0x42373065). As we currently do not release more than 5 minor >> releases, the single character should be always fine. Major number >> is currently changed roughly every year, which gives us space >> for next 250 years (maximum allowed number would be 259.9). >> ================================ >> >> >> The timestamp field also doesn't make sense to me. Assuming that >> is a hex number, it has a LOT of digits and >> https://www.epochconverter.com/ >> tells me that it is sometime in 2741 >> >> There was some issue with it because I was taking signed int. > I fixed it. > >> Maybe you have the endianness of some of the fields wrong. >> >> Yes the endianness was wrong. > I have uploaded the code to a github repository so that it can be > visible and progress can be trackable. > > https://github.com/thelunatic/gcno_dumper.git > > I am working on figuring out how the file is organised, I'll > post the generated txt file soon. > >> But this is what it takes to understand it. :) >> >> --joel >> >> >> On Sat, Jul 14, 2018 at 4:29 PM, Vijay Kumar Banerjee < >> vijaykumar9...@gmail.com> wrote: >> >>> Hello, >>> >>> As suggested by Joel, I have tried to figure out the structure of >>> the gcno files and written a gcno dumper. >>> This is not complete yet, I'm still working on it and I'll keep adding >>> to it as I "decode" the gcno files. >>> >>> I'm attaching the c++ code, the gcno file I'm testing on and the txt >>> file generated from it. >>> >>> please have a look. Is it moving in the right direction ? >>> >>> On 12 July 2018 at 03:56, Vijay Kumar Banerjee <vijaykumar9...@gmail.com >>> > wrote: >>> >>>> I have filed a ticket for gcov, as suggested by Joel. >>>> >>>> https://devel.rtems.org/ticket/3468 >>>> >>>> -- vijay >>>> >>>> On 8 July 2018 at 01:43, Chris Johns <chr...@rtems.org> wrote: >>>> >>>>> On 8/7/18 7:51 am, Vijay Kumar Banerjee wrote: >>>>> > On 8 July 2018 at 01:08, Joel Sherrill <j...@rtems.org <mailto: >>>>> j...@rtems.org>> >>>>> > wrote: >>>>> > >>>>> > On Sat, Jul 7, 2018, 2:33 PM Chris Johns < >>>>> ch...@contemporary.net.au >>>>> > <mailto:ch...@contemporary.net.au>> wrote: >>>>> > >>>>> > On 5 Jul 2018, at 3:07 am, Joel Sherrill <j...@rtems.org >>>>> > <mailto:j...@rtems.org> >>>>> > <mailto:j...@rtems.org <mailto:j...@rtems.org>>> wrote: >>>>> > > On Wed, Jul 4, 2018, 3:06 AM Chris Johns <chr...@rtems.org >>>>> <mailto:chr...@rtems.org> >>>>> > > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> >>>>> wrote: >>>>> > > >>>>> > > How does this fit into the RTEMS Tester tool? >>>>> > > >>>>> > > >>>>> > > If you want to run gcov or lcov on uninstrumented >>>>> executables, then covoar has >>>>> > > to read gcno and write gcda files. And we have to then run >>>>> gcov or lcov as >>>>> > > normal. >>>>> > >>>>> > >>>>> > This is just a description of how it works. Not a particular >>>>> change. >>>>> > >>>>> > > >>>>> > > It is the path to another report format. >>>>> > >>>>> > I am not sure I understand how we make this work and how we >>>>> support the >>>>> > user. Is >>>>> > this an option to 'rtems-test'? >>>>> > >>>>> > The aim of the 'rtems-test' command is to provide a >>>>> documented user >>>>> > interface. >>>>> > Providing direct access to covoar adds more documentation and >>>>> > complication to >>>>> > the test tool. For example how does the user wanting gcov >>>>> output get to the >>>>> > trace files? The user would need to step into how we >>>>> implement coverage >>>>> > and that >>>>> > is an interface we will not document and change. >>>>> > >>>>> > >>>>> > I wouldn't want a user to invoke covoar directly. It is just a >>>>> coverage >>>>> > reporting variant at this point. I doubt it will ever be the >>>>> default report >>>>> > format because we have details in the native reports that I >>>>> don't think you >>>>> > can get ever with gcov. I think the native format is closer to >>>>> what you >>>>> > would use on an analysis for the highest level of coverage. >>>>> > >>>>> > once covoar can generate the gcov reports, we can add it as an >>>>> option to rtems test. >>>>> > we can generate a file with the list of the notes/trace files from >>>>> the script >>>>> > which will work as an >>>>> > input to covoar, the user won't have to do anything manually. >>>>> >>>>> Thank you. I now understand. >>>>> >>>>> Chris >>>>> >>>> >>>> >>> >> >
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
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
