On 1/24/19 4:19 PM, Joel Sherrill wrote: > > > On Thu, Jan 24, 2019 at 8:46 AM Jiri Gaisler <j...@gaisler.se > <mailto:j...@gaisler.se>> wrote: > > > On 1/24/19 2:19 PM, Joel Sherrill wrote: >> >> >> On Thu, Jan 24, 2019, 6:38 AM Jiri Gaisler <j...@gaisler.se >> <mailto:j...@gaisler.se> wrote: >> >> Small patch to fix covoar to work with TSIM coverage files. >> It should be noted that covoar erroneously marks some code as >> uncovered while it is marked as covered in the coverage file. >> This seems to be due to incorrect parsing of the symbol table >> in the exec file. I will file a ticket for this on trac .. >> >> >> Is this the entry and exit code of a method or something else? >> The switch to dwarf info seems to have caused that and not >> marking assembly from inlined methods. > > I notice two problems: the first instruction in a range is > sometimes marked as uncovered: > > 4000807c <_Freechain_Get>: > Freechain_Control *freechain, > Freechain_Allocator allocator, > size_t number_nodes_to_extend, > size_t node_size > ) > { > 4000807c: 9d e3 bf a0 save %sp, -96, %sp > <== NOT EXECUTED > 40008080: ba 10 00 18 mov %i0, %i5 > > return _Chain_Immutable_head( the_chain )->next; > > 40008084: f0 06 00 00 ld [ %i0 ], %i0 > > even though it is marked as executed in the coverage file. The > second problems is that the size of ranges is sometimes off by one > byte, e.g. 21 bytes instead of 20. This can only be seen when > debugging covoar in gdb. > > > I recall that the CoverageReaderTSIM code did an offset of +1 to +4 > from the address. Perhaps it just needs to be 0-3. :)
CoverageReaderTSIM calls aCoverageMap->setWasExecuted() with correct addresses from the coverage file, I checked that through debug prints. Checking the final annotated sources, I can see that the first instruction in each range is always marked as uncovered, regardless of coverage data. The remaining instructions seem to be annotated correctly. For some reason, theCoverageMap->wasExecuted() in ReportsBase.cc does not return the correct data for the first address in each range. My C++ skills are rather poor, so I have a hard time debugging all the object nonsense to understand why the coverage map is wrong. Maybe my mind will clear a bit after some food ... :-)
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel