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 >>>> >>> >>> >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
